Archived Forum

The code that I posted yesterday can reveal the length of the LED's pulse.  The next stage is to capture what's going on with the LED while also recording energy flow through the meter.  That's what today's offering does.

MeterAnaylysisTool checks the state of the LED once every mains cycle.  If the LED has just turned on, a flag is set.  If it goes off again within 50mS, then it must have been a pulse in which case the flag is cleared and **LED_PULSE** is sent to the Serial Output.  If 50mS goes by with the LED still being on, then a **LED_ON** event is declared; and  similarly for **LED_OFF**.  I did start to use an interrupt for this but found that it didn't help.  With LED pulses being around 35mS in duration, polling every 20mS should allow all relevant data to be collected. 

The tool also displays energy flow through the meter each second, along with a timestamp.  No limits are set, it just winds its way up and down an endless line of Joules.  When importing power using a well calibrated system, one would expect to see the LED pulse every 3600J.   Using a faster serial rate would be a worthwhile improvement. 

Also attached are two sets or results when the PV was active and our consumption was moving to and fro across the interesting zone.  Both generation and consumption was changing during these periods, but that's surely all to the good.  Somewhere in the data there will hopefully be examples of most types of operation; importing or exporting at small and large rates, and changes of direction etc.  In stable conditions, a more objective schedule of tests may be possible. Maybe someone would like to port this data into a spreadsheet and tell me what it all means  ;)

Each of my power-routing systems appear to be biassed towards the exporting of power.  When the system is operational, the meter's LED is nearly always on.   With a safety margin of 0W, I've never understood why this is happening.  I wonder how other systems behave in this regard?

Each of my power-routing systems appear to be biassed towards the exporting of power.  When the system is operational, the meter's LED is nearly always on.   With a safety margin of 0W, I've never understood why this is happening.  I wonder how other systems behave in this regard?

I now think this is the anti-creep mechanism cutting in, so no problem.

To help with our understanding of how digital meters work, here is a virtual one.  Just load it onto an Arduino and follow the instructions on the screen.  I think it matches the basic operations of inport and export for our Landis 5235A meter OK, but the anti-creep mode may need a bit of tweaking.

Do give it a try, and feel free to make any changes that may be appropriate. 

Sketch attached, plus an output file.

Out of interest Robin, do you have a feel for how easy it would be and how the accuracy may be affected were this code to be integrated within the MK2 sketch? 

I ask because, with my system I have the MK2 sketch running but with the additional transmission of energy consumption calculated and then correlated against the enviR/Optismart (which does the same thing as your sketch).

While the enviR is the most accurate reference when the LED on the meter is flashing it is hopeless when the LED is constant (during export). It would be interesting to know if a pulse reader could be incorporated with the MK2 and the pulse reader over rides the CT/VT when the system is importing from the grid and the CT/VT over rides when the system is in export mode.

Ian, I don't see how this simulation could be usefully incorporated into a working PV power router.  As written, its sole purpose was to get people thinking about how their meters work, and talking the same language.  In particular, it allows the anti-creep mode to be investigated, the manuals are not at all helpful about how this feature works.

My Mk2 code (the mini version) can already detect and categorise LED events.  All LED events, most of which are chargeable, are displayed to the Serial Monitor but the algorithm doesn't currently make use of that information.  Tweaking the value of safetyMargin_watts may allow a bit of additional power to be gleaned out of the grid - monitoring the LED's behaviour would show whether any charge was being incurred.

When the house is importing power, Mk2 effectively switches off, so I don't understand why you would want the normal V & I sensors to be over-ridden.  If a "chargeable event" were to be seen while Mk2 is busy diverting surplus power, that means there has been a drift between the two measurement systems.  In that situation, I think it would be better for the diversion algorithm to be throttled back a bit, possibly by increasing the safety margin's value. 

I wasn't thinking of the simulator version - just the fully operational one.

The way that my system works, which uses your core, has three general operating areas. The first is import (when the PV is insufficient to provide any surplus dump). The second is dump (when there is sufficient PV to drive the dump and, provided the system is properly tuned, there is little or no export). Thirdly, there is pure export (when the PV dump has been fully charged and there is no place to send the surplus power aside from back to the grid).

In the first operating area it is possible to correlate the enviR with my version of the energy monitor because both with generate a reading (the enviR timing pulses from the meter). In the second area it doesn't really matter as the surplus power is being sent to the immersion heater and the export should be very near zero (ignoring the safety margin). In the third region my enviR  cannot measure anything because the LED's on the meters stay on permanently. My sketch can measure though, albeit within the accuracy that the hardware will allow.

The point of my question was to understand if you have made any measurements to see how long it takes for the microcontroller to check the static state of the IO pins which are linked to the LDR's and if, by having them embedded within the MK2 sketch (I hadn't noticed them set to read mode in the version that I used) they had any effect upon the operation of the original sketch (error, drift, etc).

The thought that I had with regard to my hardware was to incorporate capability within it which would read the light pulses when the system is working in mode one while in modes two and three it would use the current and voltage transformers instead. I may then consider sending an extended set of data up to Pachube as an extended project with emonbase which incorporates a lot more information than I am currently sending via enviR.

What you have Robin is the basis for a truly accurate energy monitor, I've been disappointed in the way a number of the commercial monitors work have a look at-

http://www.talkingsolar.co.uk/index.php/forum/7-arduino-circuit-discussions/750-robins-mk2-and-the-meter

This shows how the Eco Eye Smart PV sees the power being used, unfortunately instead of averaging the power like the supply meter does it records the peaks as being import. Now my thoughts are. If the Mk2 CT input could be used to separately measure the averaged power like the meter does, and generate a signal that mimics the CT but with a signal that follows what the meter is responding to i.e. no peaks and dips, then this could be used to feed whatever monitor is in use via a separate output. As my Arduino skills are about at the fading LED stage I'm going to throw this idea to the mercy of those who know better. I'm also thinking this would by applying the low pass filter be able to clean up the CT signal at low levels.

Ian, just to recap, the sole purpose of my Mk2 router is to divert surplus power to a dump load.  This is achieved by rapidly switching the load on and off using a simple algorithm.  To my mind, one of the great benefits of the Mk2 is that it needs no calibration.  Using only a single point of measurement, the algorithm serves to balance import and export so that there is no net flow through the utility meter.  Hence there is no charge to the user, and no energy is lost to the grid.  The router just sits there 24/7 waiting for surplus power to appear.  Sorted.

Your system, however, is more ambitious.  Having arranged to dump surplus power as above, you also require accurate stats to be available at all times.  This may imply the need for accurate calibration - but not necessarily.   At all stages of the day/night, the most accurate indication of your expenditure is that provided by the supply meter via its LED.  If you want to use that source of data for stats purposes, rather than equivalent data from the V&I sensors, then that would seem a perfectly reasonable thing to do.  The cut-down version of my sketch already includes code for categorising LED events so it would be an easy matter to obtain an accurate tally of chargeable events, each one worth 0.001kWh of expenditure.  Because the system would just be relaying events from the meter, there would still be no need for any calibration.

While surplus power is being actively diverted, there is bound to be some degree of drift between the Arduino's assessment of energy flow and that of the utility meter - both nominally zero.  When using a digital meter, this drift may lie within the anti-creep parameters, in which case no import pulses would be seen.  But if there were any drift towards export, that effect would be undetectable using a standard digital supply meter.  Hence my interest in having a disc-style meter in series with the existing one so that the amount of drift can be accurately monitored throughout the entire range of operation (0 - 3kW of surplus power).

I will soon have a couple of additional meters to play with: a used 5235 from eBay, and a disc-style unit kindly donated by noah.  Over the next couple of weeks, these will be connected up so that the behaviour of my Mk2 setup can be better  understood while in its operating mode.  Once the amount of surplus power falls below zero, I have little interest in monitoring the imported power - the only thing that matters to me is that the triac and load are firmly off.  That's another good feature of Mk2.  The immersion goes off within around 30mS of the kettle going on.  I've yet to see a phase-angle controller which can deliver that kind of performance!

richmc: What you have Robin is the basis for a truly accurate energy monitor, 

Thanks for those kind words, Rich, but I think such praise is undeserved, and may possibly be misleading to some.  For a start, my system of measurement was copied directly from that used by the standard OEM V&I sketch in the Building Blocks page.  The original code can be found in the eMonLib library function, calcVI().

My system is actually less accurate than the original on two counts.  Firstly, my sketch never checks the voltage of the reference supply.  Secondly, the hardware setup - for good reason - is essentially uncalibrated.  Having recently fitted a less-sensitive CT to my rig in the garage, I have never bothered to amend POWERCAL because I genuinely believe there is no need to do so.  Mk2's ability to divert surplus power does not depend on its calibration.

The best way to measure imported power using a digital meter is undoubtedly to monitor the meter's LED activity, which the cut-down Mk2 code can already do.  Similarly, the best way to measure exported power would undoubtedly be to install a second digital meter in the opposite direction and then monitor its LED activity.  An "energy monitor" of this type would record the passage of every WattHour's worth of flow in either direction with total accuracy. 

Unfortunately, for the purpose of diverting surplus power, monitoring LEDs is always just too late hence my alternative approach :D 

Just adding to Robin's reply: In essence, his rig is controlling towards zero, therefore symmetry of the calibration about zero is the important property and the scale factor of the calibration has little effect on the overall result. If you measure 55 J each way instead of 50, it makes no difference - you are still back to where you started from. And that's how it works.

Thanks Robert.  Yes, it is the flow of energy through the supply meter which my rig is controlling towards zero.  It does this by keeping the level in the accumulator (energy bucket) close to a constant value.  This value happens to be 1800J, but the number itself is not important, nor is the absolute calibration. 

The only aspect of importance is the system's linearity, i.e. the consistency of its calibration across the +/- 3kW range.  Why plus and minus?  Well, when minimal surplus PV is available, the instantaneous rate of import during those (infrequent) cycles for which the triac is 'on' could be up to 3kW.  Similarly, when plenty of surplus PV is available, the instantaneous rate of export during those (infrequent) cycles when the triac is 'off' could again be up to 3kW.  During all other cycles while the router is active, the current flow at the supply point will be somewhere between these two extremes. 

If the measurement system is truly linear, then the symmetry of the calibration either side of zero Watts will be perfect.  With some of the strange waveform profiles that have been posted, I'm amazed how well Mk2 actually works!

Thats what I'm getting at Robin.

As you say the waveforms are weird, but thats what's happening to the power in "real life" what I would like to see is the waveform as the supply meter sees it, after all thats the important one as thats what we are charged on, so a "simulated" CT output that could be fed into any energy monitor that actually reflects what the supply meter is doing would be of more use than the false (although accurate) thats being used to calculate usage.

Now as I said I would have no idea how to go about this, I'm guessing some code inserted into the sketch like your meter simulation, outputting to an opamp with gain adjustment for calibration(dirty word, but relates to energy monitors). The idea of adding another meter seems over the top if the Arduino can be called to do the same job with a simulated meter?

And I stand by my "kind words" what I meant was the idea of simulating the meter could be the basis of an accurate energy monitor. As we've said all along your Mk2 design doesn't depend on accurate measurement but good response to the feedback loop.

"the waveforms are weird, but that's what's happening to the power in "real life" what I would like to see is the waveform as the supply meter sees it, after all that's the important one as that's what we are charged on, so a "simulated" CT output that could be fed into any energy monitor that actually reflects what the supply meter is doing would be of more use than the false (although accurate) that's being used to calculate usage."

I don't understand what you're trying to get at here. If the supply meter and the c.t. are on the same cable, they both see the same current. Within the limitations of the sampling rate of each, they will surely measure the same quantity. The same goes for the voltage.

Are you trying to say that because Robin's algorithm doesn't calibrate voltage and current independently, the absolute power calculation is wrong? If so, you're probably correct. The easy answer will be to remove Robin's POWERCAL and revert to separately calibrating the current and voltage, as in the demo sketches, at which point the power calibration should be correct and should agree with other measurements. I believe Robin did it this way to reduce the complication and number of calculations.

What is totally confusing me is the notion of an op-amp output. What quantity are you intending to transmit and to where and for what purpose?

I'm also confused by "simulating" the meter to accurately measure consumption. Don't you mean "emulate"?

We are at crossed purposes here, what I'm trying to say is the monitor systems I've come across like the Eco Eye et al see literally what is produced by the CT, a waveform that exceeds and dips across the mean, they ignore the dips as they are considered as export but count all the peaks as import so giving an inaccurate report on energy costs as recognized by the consumer meter. Robin has already shown it's possible to simulate or emulate the action of the meter.

"If the supply meter and the c.t. are on the same cable, they both see the same current."

They may. But the supply meter responds in a completely different way, to put it crudely it seems to average out the power consumption, I have graphs from the Eco Eye Trax software showing when the diverter is working I'm importing power when my supply meter says not, that's how the system works. What I'm after is a way of measuring the power in the same way the meter does, not to use it to influence how the diverter works that's perfect, but to allow me to monitor power usage the same way as the supply meter. My thoughts are that the Arduino should be able to handle a routine to mimic the supply meter and give an output  so that it can be used to show the actual power as the meter sees it.

The idea of a buffered opamp output  is to have a "cleaned up" signal that does not show the burst fire signal but shows a signal the same as the supply meter would interpret it. The quantity of the signal would be the same as the signal the CT is seeing but without the burst fire, that seems to confuse a lot of measuring devices. Where and what purpose is to give a realistic signal for any measuring device to use. I only see the opamp output as a way to fine tune the signal level to match the measuring device.

The sole purpose of my Mk2 arrangement is to maintain zero net flow of energy at the supply point.  It does this by pulsing power to the dump load using a simple on/off algorithm.

With only one thing to do, Mk2 thankfully seems to perform its task pretty well.  So, whenever it is actively diverting power, the net flow of current through the meter can reasonably be assumed to be zero, whatever any other piece of clip-on kit may be saying.

OK, but when is the algorithm "actively diverting power"?  I would suggest having a range of energy bucket values, within which the algorithm is deemed to be active, and beyond which it isn't.  How about, say 1300 - 2300J?  The numbers are really not important, just so long as they are not too restrictive.  Mk2 does need some headroom within which to operate.  While surplus power is being actively diverted, the energy bucket's level should always be within a couple of hundred watts of the 1800J threshold. 

If you do go down this route, you may wish to ensure that your system is calibrated a bit better than mine :D

richmc

Ah, I think I understand a bit better now - you mean the envelope of the current waveform (taking direction into account), not the current waveform itself. And you're interested in getting the same readings as your tariff meter (whether or not that is truly accurate, in other words ignoring power that is below the creep threshold, etc.).

While my PV Router is diverting surplus power, it has always been unclear to me what the supply meter is doing.  Sometimes the 'export' LED is on and sometimes it's not.

To satisfy my curiosity, I've bought a digital meter (an Ampy 5196) which appears to operate in a similar manner to our Landis 5235A.  When connected in series, their pulse rates match to around 1 part in 400.

I needed to pass current through my new meter in both directions.  This was achieved using a pair of 2-pole switches as shown in the attached diagram and photo. 

To measure the current that was flowing, I constructed a sketch which emulates the operation of the meter.  This uses a standard CT and voltage sensor and monitors the energy flow adjacent to the meter.  By sneaking an extra wire through the CT only, the emulator could be advanced relative to the meter using the current drawn by a 60W light bulb.  This allowed the two LEDs to be synchronised. 

With the sketch as attached and POWERCAL correctly set, the operation of my emulator appears to closely match that of the digital meter.  Their LEDs operate nicely in tandem as current flows in either direction.  To understand how the upper and lower limits for the meter's accumulator (aka energy bucket) operate, please consult the sketch.

The attached set of results record the situation when different periods of export were interspersed with import.  Unlike the real meter, the sketch displays how much energy has flowed between each consecutive pair of charge-points.  Any loss of energy can therefore be detected. 

The rest of this post can be summarised as "Mk2 works fine just as it is", but if you want the more complete account, please read on ...

Turns out that the meter's operation is even simpler than I'd previously thought.  Having bought some energy from the grid (seen as a pulse at the meter's LED), the next 3600J's worth of space (headroom?) is then available for energy to be freely moved back and forth.  This 'no-penalty' zone starts precisely where you were when the last pulse occurred, and ends when the next pulse is due. 

Say that the kettle goes off just before the next pulse is due.  If any surplus PV is available, Mk2's energy bucket starts to fill.  After 1800J of export, Mk2 starts to allocate power to the dump load.  At no stage has the meter's 'export' light come on because we're still located within its 'no-penalty' window.

OK, but what if the kettle goes off just after a pulse has occurred?  What happens then is that the action of filling Mk2's energy bucket causes the 'export' LED to appear at the meter.  While export continues, some of the energy that you've just paid for is being lost to the grid.  Without doing anything differently, you have inadvertently strayed outside the 'no-penalty' zone and are paying the (very small) penalty for so doing.

So wouldn't it be better to operate Mk2's energy bucket at a lower level?  The short answer is yes, *** BUT *** you'd have to be certain that your system would never encroach the lower limit (0J) during normal operation.  Retaining the 1800J threshold provides a huge margin of tolerance for poorly calibrated Mk2 systems. 

Although technically a good move, the financial benefit that could be obtained by lowering the operating threshold is tiny.  Each time that surplus PV becomes available, the 'phase' (correlation?) relative to the meter's internal thresholds will essentially be random.  Some start-up events will be nicely aligned with the meter's internal thresholds (hence no loss of energy), but others will incur some loss as Mk2's energy bucket fills.  On average, let's say we lose half of the bucket's threshold capacity each time, i.e. 900J. 

If we were to use a lower threshold, say 200J, then we would lose on average only 100J per startup, that's a benefit of 800J each time that surplus power becomes available.  If periods of surplus power were to be interspersed with periods of power consumption at a rate of once per minute over a period of six hours, that's a potential saving of 0.288MJ.  One kWh is 3.6MJ, so the potential saving per day is around one penny. 

The scenario that I've outlined here is clearly an extreme case.  On most days, there would be far fewer startups than I've suggested, hence even less benefit for reducing the threshold value.

With less than around 17W of forward current, the Ampy's anti-creep mode cuts in after about 4 minutes.  While in this state, the internal register is not updated so no charge is applied.  Nice to know but tedious to test! 
 

There's a law of diminishing returns here. Any import is probably only micro-pence. Even if it was a penny or two it would take a long time to pay for any tinkering time and especially for any hardware changes.

I think what I'm trying to say is, it works bloody well already!

P.

Sure, Paul, I quite agree.  Glad you approve!!

As the originator of this baby (beast?), I want to make sure that it's working as well as possible.   For anyone who's not started to build their system already, it's good for them to have the best guidance that's available.

The original Mk2 design does indeed work fine, as demonstrated by another tank of DHW for us today :D