Archived Forum

We'll soon have more forks than a Frankie and Bennys!

P.

No, that's only with Github :D

wow, i cant keep up with all of this. I haven't spoken to the wife for ages!

Actually, Github (or maybe another repository) would solve a lot of these forking problems.

(Don't say that out loud).

P.

Github (or maybe another repository) would solve a lot of these forking problems.

That depends on the path that the developer has taken to get to version N+1.  Over the last few months, I've acquired all sorts of useful bits and pieces, and things pretty much get cut-and-pasted together as required to meet the need of the day. 

When writing code for Marconi some years ago, all softies had to abide by the official Revision Control system that controlled everything.  The dates of future builds were known - more or less - and code had to compile and link to everything else by that deadline.  Then there were all those offline tests, hundreds of them, and then the system tests ...

No thanks, this ad-hoc arrangement suits me just fine :)

With some welcome sunshine today, I've loaded the new code onto my rig in the garage, and it does indeed behave as expected. 

In WORKCHECK_MODE, I was getting a few 1uS readings amongst the normal ones.  This appears to be because the double print statement is too much for the processor to do given that it has just been overloaded to the point of complaint.  This effect can be avoided by printing these statements on consecutive loops (at around line 540):

#ifdef WORKLOAD_CHECK
  switch (displayFlag)
  {
    case 0: // the result is available now, but don't display until the next loop
      displayFlag++;
      break;
    case 1: // with minimum delay, it's OK to print now
      Serial.print(res);
      displayFlag++;
      break;
    case 2: // with minimum delay, it's OK to print now
      Serial.println("uS");
      displayFlag++;
      break;
    default:; // for most of the time, displayFlag is 3          
  }
#endif
 

Just as I was about to capture some decent readings with >1kW of PV, the clouds appeared.  But with around 350W of total PV still available, that was just enough to keep the system ticking over so I grabbed a 60s 'tallymode' run with the ADC in free-running mode.  These results have been processed on sheet 3 of the revised spreadsheet, with resulting graphs as attached (and hopefully below too).  This gives a lot of insight as to what's going on in normal mode (not anti-flicker).

Throughout this run, the net flow of energy at our supply point was approx. 125W of export.  That sounds about right, the neon was flashing at around 2-3 Hz (each active cycle consumes 60 Joules).

The twin peak effect at around -1500W is caused by the floating nature of the non-invasive CT.  This effect can be seen whenever there's an isolated cycle of the dump load (or anything else for that matter).  The first half of the active cycle is always seen to contain less energy than the second half. 

The small peak at around -2750W is the signature of two (or more) active cycles occurring consecutively.  This allows the triac to remain on for the full duration of a 20mS measurement window.  Because of the interleaving of the measurement and power distribution cycles, this is not the normal behaviour at low levels of surplus power.  The energy values for each of the 3000 recorded cycles were all in one peak or another, the 'hit' values being:  +100W: 2688;  -1200W: 145;   -1700W: 156;   -2700W: 11.  I think this means that there were 145 firings of the triac for one cycle, and 11 firings for two cycles. 

During this run, the free-running Mk2i code recorded 96 energy calculations per mains cycle (average).  My rig has not been accurately calibrated, hence the 3kW dump load appears to be around 10% lower than its proper value.

Robin, I've just built one of these using this new code and it's great. Using it in flicker mode first. I would like to have a second output pin for if the solar output (less house load) is greater than the immersion load for example. I have 11 kw of pv. I don't have any knowledge at all with sketches and have seen that you have mentioned elsewhere you just need to put in an output for a larger bucket size. I'm unsure how to do that and where to put it. I guess it would be possible to use the same output as the onboard bucket overrun led but guess this isn't ideal. (My led flashes when theres no load on at all, after a while, but i guess that's because i haven't got the values quite right yet.)     

Hi Nick, I'm pleased to hear that this latest version of the Mk2 Router is working nicely for you.  Having resisted going down the road of interrupts for some time, it does appear to be the optimum way to go. 

An alternative scheme for diverting surplus power should be fairly straightforward once the underlying requirements are known.  An anti-flicker algorithm for 11kW will be interesting.  Hopefully you will be able to distribute the power across several loads.  On the measurement side, you would presumably need to re-scale your current sensor for all that power.

If you send me a PM with some more details, I'm sure that some suitable scheme can be devised.  The Flicker Demo tool that's mentioned in the index at http://openenergymonitor.org/emon/node/1757 may be a good place to start.

Thanks Robin.

I was wondering about the current transformer, as at the moment I have the 50A one from Rapid as mentioned in your post. It has the internal burden resistor and at the moment I have not added an external one. What I've found is, obviously, it only does 0.33v at 50A so my readings are very low and I have a PowerCal value of 0.81.But it works fine at that. If everything is working as it should then the actual current to be measured  should be virtually zero when generating PV so do you need a larger CT?. What happens  even in a small system when your generating no PV and have heaters, oven, kettle etc on in the house. The current transformer will be measuring a large current. Does this not overload it or is it ok to run saturated?

I will PM details of the system to you, It's quite complex with battery backups (but they will use most of the spare PV initially to recharge the batteries. That's automatic and built in to the backup units), so it's probably only going to be like having 2 3KW elements run off your system switched in sequence. First one to be used for the first 3KW of surplus PV and then when above 3KW that would be permanently on and the second element would then be in anti flicker mode.

PS, I have to admit I'd bought a couple of commercial power diverter units but I don't think I'll be fitting them!

If everything is working as it should then the actual current to be measured  should be virtually zero when generating PV so do you need a larger CT?.

Although the average current over a period of time will be close to zero, the current within individual cycles will certainly not be zero.  Between adjacent cycles where the triac is 'on' and 'off, there will be a net difference of 3kW (or whatever your dump load happens to be).

What happens  even in a small system when your generating no PV and have heaters, oven, kettle etc on in the house. The current transformer will be measuring a large current. Does this not overload it or is it ok to run saturated?

So far, our CT hasn't objected to running at higher currents such as taken by our 8kW electric shower.  And thanks to the protection diodes, neither has my Arduino.  Some constructors have added a gain stage immediately after the CT in order to make better use of the ADC's range.   Video footage that I've posted of the basic Mk2's operation with a disc-type meter in our supply line show that good balance can be achieved without this refinement. 

Robin,

This means if the load is only just slightly more than the surplus PV the triac will turn on shortly after turning off. 

My reason for placing a restriction on the off->on event was that the consequence of delaying this transition is at worst some loss of energy to the grid when the bucket overflows.  Whereas delaying the on->off transition could result in a direct cost to the user.  Loss of micro-pennies to the grid seems less bad than having them added unexpectedly to the bill.  With 80% hysteresis in place, it's difficult to see how the a/f measures can be further tightened without significant less of energy at certain times.

I can't recall the state of the anti-flicker demo tool that I posted some weeks ago.  It would make sense for this to be aligned with the latest version of Mk2, i.e this one.  If it needs to be updated, I will try to do that and post a new version.

Yes I  understand its better to lose energy to the grid rather than the the other way round, but but as it runs at the moment if the triac is on for more than the delay time the delay time is 'used up' during that on time so the triac can come straight back on. A delay time starting at 'triac off' would still result in energy going to the grid and no import.

As I'm trying to set up an additional  traic anyway- this could be activated to take up any energy bucket overflow during any A/F delay time

"this could be activated to take up any energy bucket overflow during any A/F delay time"

Nope. Flawed logic there I'm afraid. I fell into that trap until I realised that both are using the same "bucket" and once the bucket is full, it's full. And once one has put a transition onto the supply, it applies to both.

If you want a second load to take over when the first one can't take any more energy, you need two more thresholds each slightly (i.e. a couple of 'load.cycles' , say 120 - 150 J) above the corresponding original thresholds. But both need to feed into the anti-flicker timer.

Of course, if you are generating more than the first dump can dissipate, you can leave that permanently on and the flicker restriction applies to the second triac only.

This all sounds very complicated when written down in words.  I've just sketched out a couple of pictures and I think there are various ways of doing it.  Robert's idea for having multiple "tiered" limits sounds fine but they will consume some of the operating range that the first triac has to play with.  Push the limits outwards, and cost is likely to be incurred unless the system's calibration is spot-on.  Bring them in towards each other and you're likely to have to hold the triac(s) off sooner to avoid infringing the a/f timescales, hence lost energy.

Another approach would be to have just one pair of limits as before, as close as possible to the 0 and 3600J points, but to always switch, say, the lowest valued triac when a limit is reached.  If that doesn't have sufficient effect, then the next triac can be switched too after waiting for a few cycles.  Unlike the existing algorithm, this variant would need to maintain knowledge of the state of each triac. 

I had a quick look at the a/f demo tool but got bogged down with the different formats between it and the Mk2i code.  One uses integer maths, the other is floating point.  For demo purposes, FP is probably best.   May have another go tomorrow ...

Oh I'm daft- Of course the first triac won't turn off because the first dump can't handle the surplus! Forgot that bit.

On second thoughts, I think Robert's explanation/ ideas on this one are better than mine. 

Time to bow out gracefully ...

All your sketches are really complicated to me as my computer programing knowledge is based on 'basic' and that was from x years ago and I cant remember that!

If you go back to basics (not BASIC) the meter 'window' (AKA 'bucket') capacity is 1 Wh or 3600 J.  For a 3 kW heater, 1 load.cycle = 3 kW x 20 mS = 60 J.  If your first load can't absorb the energy, I think you can afford 2½ cycles' worth - 150 J - that's only 4and-a-bit percent of the 'bucket', so setting the 1st load's thresholds 2% lower than you otherwise would, and the 2nd load's 2% above won't eat into your margins all that much.

(Or to put it another way, of your calibration was out by 2%, you'd be there anyway and not know it).

Knowing the state of the triac won't help much, because it isn't the only thing controlling the load, there's the thermostat as well...

Tinbum:

If you're struggling with C++, there's a reasonably good free on-line resource here

OK, here's an updated version of my Flicker Demo tool that works in just the same way as the Mk2i PV Router.  (The previous version did so too, but some of the code had been rearranged).  This demo works best with a bulb as the dump load, much easier to see than the on-board LED.  Note that pin 13 LED shows the triac state, not the overflow status as per the corresponding Router sketch.

It uses FP maths, so the various thresholds are obvious.  As posted, the min time between triac activations is 5s.  This value has been deliberately set long so that overflow of the energy bucket can be easily seen.  With 1500W of simulated PV, look for 3600 on the display.  That's the overflow.  Then reduce the time constraint to 3s and it disappears. 

As posted, Mk2i only uses 60% of the bucket's capacity for anti-flicker measures.  This range can be extended at risk of running outside the sweet zone of 0.001kWh that's allowed by most meters.

Creating a phase-angle version of this tool, suitable for higher powers (eg 11kW and 4 triacs), should be straightforward enough.  If this would be helpful, let me know and I'll be happy to write one.  But it may not be for a week or two ...

Thanks Robin- it'll take me a while to digest all the info especially as I was up nearly all night trying a few ideas myself.

I'm not really wanting to go down the phase control route for this part as I'd like to run loads other than just resistive loads, the main ones being battery chargers. I have two sets of batteries, one set is near to the DNO supply and the SMA backup units so that is totally controlled by the SMA backups automatically. The other set is more remote and this is where i'd like to use the battery chargers off the surplus PV.

The actual flicker doesn't seem to be noticeable here and wouldn't effect anyone else as we have our own transformer off the high voltage line. Its the fact that the switching is either off or on and nothing between that's the main advantage to me.

In my experimenting last night i have actually come up with something that seems to work (but no where near your standard), using two triacs. 3 variable heaters and a kettle. (didn't run out of tea to keep me awake)!   Running it through a spare 3 phase meter it results in the LED staying lit, but i must admit i have no knowledge of sketches and its a bit of a bodge using the bucket overflow LED  part of the sketch to drive the second triac. If a little power goes into the grid I'm not worried- its far easier than watching the sun and walking over to turn the chargers of and on individually depending on how bright it is. I have another spare 3 phase meter so i may wire this up to check the power i would lose to the grid.

Problem is I'm a perfectionist and I wont be happy with myself till its spot on!!!!

OK, I do recommend working with the demo tool though rather than the actual Mk2i code.  With its FP maths, the demo's logic is much easier to follow/modify.  Unlike real life, the simulator is 100% accurate, so there's no doubt as to the actual rating of your loads. Interesting 'near-limit' conditions can be easily set up and analysed/recorded/repeated.  The demo tool will run on any rig that Mk2 code runs on.  It just needs a voltage source and ideally a triac on pin 9.

Using the simulator will also allow uninterrupted access to your kettle :)

If some loss of surplus power to the grid is not a problem, then devising a compliant on:off scheme for 11kW should be entirely straightforward, albeit it not very efficient when conditions change.  It would still be a 1000000 times more efficient than "watching the sun and walking over to turn the chargers of and on individually depending on how bright it is" - heaven forbid!! If you're not happy with changing things around in the software, just send me a PM with all the details. 

Tinbum,

If you've got your own step-down transformer, then clearly flicker is much less of a worry, because (I don't know about the post-2001 standard, but...) the previous rules related to the "PCC" - the point of common coupling, which in your case is the junction where the line to your transformer joins up with your neighbour's supply. The transformer itself will obviously add to the supply impedance so the flicker on the supply side will be less than on the low voltage side. If you're on good terms with your neighbours and they can't see any flicker (or you can't measure it in their houses) then I would think everyone is going to be happy.

For anyone with their own step-down transformer, the "neighbours" could be miles away ;)

How's this for a possible anti-flicker scheme for 3 triacs/loads (as attached).  It's basically three 1Wh windows stacked on top of each other.  Within each zone, the relevant triac operates with hysteresis between its specified limits.  The other two triacs will be in a constant state, either on or off.  There would still need to be an overall timer to prevent any transitition from occurring too soon after the previous one. 

Moving up between zones will cause some loss of real energy to the grid, 1Wh per zone.  Similarly, moving down between zones will incur a real consumption charge of 1 Wh per zone change.  For an 11kW system, this is unlikely to be seen as a problem.  While the surplus PV rate remains constant, the system should provide normal flicker-compliant operation across the full range of powers (i.e 0 - 9kW with 3 x triacs and 3 x 3kW loads).

[Update - I've just started a new thread for anti-flicker ideas at http://openenergymonitor.org/emon/node/1941 ]

With some welcome sunshine today, my Mk2i build was flashing away nicely with our panels generating 1.3 kW.  Out of consideration for the neighbours, I though it best to switch over to anti-flicker mode.  As so often seems to happen, by the time that I'd hooked up the laptop, the clouds had appeared and we were down to just 250W or so. 

No matter, there was still some surplus PV because the neon was slowly flashing.  But after switching to a/f mode, it all went very quiet.  So was there now any surplus power, or not, there was no way of knowing.  This calls for an LED or two.

Mk2i_rev2 has gained 3 LEDs.  The first one illuminates whenever the energy in a mains cycle is positive, i.e. export.  In idle conditions, this LED rattles on & off rapidly at random, as one would expect.  Although the average flow of energy may be zero, the measured energy content of individual mains cycles will be either positive or negative, hopefully in roughly equal numbers.

The second LED illuminates whenever the energy bucket overflows.  This indicates a likely loss of (real) surplus energy to the grid and should only occur when the dump-load's thermostat trips.  If this LED ever illuminates while diverting surplus power, the a/f logic/settings should be checked.

The third LED illuminates whenever the energy bucket underflows.  This indicates a likely charge for consumption from the grid.  If this LED ever illuminates while diverting surplus power, the a/f logic/settings should be checked.  [With the present logic that I've included to date for a/f mode, this should never occur because the triac is always turned off at the lower energy threshold.  But it's probably a useful safeguard to have in place in case the a/f logic were ever to change, e.g. to the symmetrical scheme which I posted yesterday on another thread].

(aside) To verify the operation of this build, I needed some serious currents to be flowing.  While checking that the CT and wires were all the right way round, I did a 10sec Tallymode run for which the results are attached.  The 'PV' was a 60W light bulb and my dump load was a 1kW heater.  From the results file, it can be seen that during the 500 mains cycles, the triac fired exactly 29 times.  Because of the imbalance between the source and sink, each firing was for only one mains cycle.  The first half of each active cycle contained power at around 455W, the second half contained power at around 565W.  Together, these values add up to just over 1kW, as expected.  With 58 cycles having been accounted for, there should be 500-58=442 cycles in which just the bulb's power is showing.  Sure enough, at around the 60W mark, there are 441 cycles, and there's one odd 'hit' at the 25W mark.  Why that one cycle went a bit awry remains a mystery.  Maybe one of the neighbours switched on a kettle ...

Sounds a great idea having the led's.

When i was fitting mine, all be it just in a testing manor, I was thinking exactly the same as the Arduino is 75m from the triacs. Of course just like you Robin, the sun hasn't shown its face since!

No LEDS have been fitted yet to my 'working' rig, only to the lash-up that's next to my PC.  If some sun were to appear, my trusty LED board may get moved back into the garage ...

That particular offcut of stripboard has done good service.  Long before Mk2 put in an appearance, it showed me how much power was being diverted by my first lash-up.  Ah, those were the days, warm and sunny, with more surplus power than one knew what to do with!

Oh Yes, my meters now averaging about 35 units a day from the grid, compared with about 6 in the late summer.

I've just moved the LED-board into the garage with results much as expected. 

With 50-100W of surplus power, the "surplusPV" LED is great.  In a/f mode, it sits there, steadily on, until the bucket's level reaches the upper threshold and then goes off while 0.6 * 3600J is dumped.  Then it comes back on again, nice and steadily.

But with approx zero surplus power, the red and green LEDs both flicker away furiously.  Maybe this upgrade needs a health warning!  I think what it really needs is a good old fashioned switch in the 0V line to the LEDs.  Then no LEDs need be lit unless I'm interested in looking at them. 

FWIW, I've used Red for underflow (pin 11), Blue for overflow (pin 12), and Green for surplusPV (pin 13) 

Anti-flicker mode may be OK on a good day, but in weather like this it's a real pain.  You can wait for ages before a pulse appears at the neon, and if you blink, you've missed it.  Normal mode seems much better when there's so little spare power available.  Wouldn't it be nice if you could switch from one mode to the other at run-time, with no need to recompile?

Well, now you can.  Mk2i_rev3 can be changed on-the-fly between NORMAL and ANTI_FLICKER modes at the flick of a switch.  The state of the input pin is checked every mains cycle and persisted for a short while.  Whenever a change of state has been confirmed, the new settings are displayed on the Serial monitor and operation continues in the new mode.  Sample output attached.

The power-distribution code is the same as before except that "normal" is now a special case of the anti-flicker logic (where the upper and lower thresholds are the same, and there is no time constraint between consecutive activations).

The code is backwards compatible so the output mode can still be configured at compile-time as before.  But, with a simple switch between digital pin 4 and ground, the new way of working feels much better.

To check that nothing unintended has crept in, I've compared this version against the previous one using KDiff3.  A superb piece of free software from Source Forge.

calypso_rae wrote: "How's this for a possible anti-flicker scheme for 3 triacs/loads (as attached).  It's basically three 1Wh windows stacked on top of each other..."

That stacked buffer idea of yours works really well Robin. I currently have 2 immersion heaters and 3 under floor heating zones connected to 5 triacs and I tried it out today with a 5Wh buffer. It behaves very well, both when the solar power rises and falls and when a hot water cylinder gets up to temperature.

I'm pleased the hear that this one worked as intended Martin.  It was only a thought experiment.

Robert suggested to me that the various zones could be overlaid rather than being stacked, and I think I agree.  That's how the 'multiload' demo works that I (eventually!) posted on your a/f thread.  By that means, slightly less energy is lost as the system moves between the various zones, I think. 

Our DHW cyclinder hasn't got itself up to temperature for a while using PV alone.  But the days are starting to get longer now.  I really must get my rig boxed up and onto the wall ...

I did have overlaid zones originally but it seemed to get confused with the 2 immersion heaters sharing the load sometimes rather than one being fully on. I need to investigate this a bit more before rejecting the idea though.

Yes, my multi-load demo tool started to work in that way too.  I ended up by turning on the lowest valued triac that was off to increase the load, but turning off the highest one that was on to decrease it,  Hope I've got that right.   I suppose it all depends on how you want to prioritise all that power. 

Although the demo seems to work OK as a stand-alone tool, I got in an awful mess when trying to transfer its logic across for my latest Mk2i build.  The two environments just weren't compatible.  In the end I gave up and started again next day.  

void increaseLoadIfPossible()
{
  // if permitted by anti-flicker restrictions, turn on the lowest valued
  // triac that is not already on.
  boolean done = false;
 
  if (cycleCount > cycleCountAtLastTransition + minCycleCountsBetweenTransitions)
  { 
    for (int i = 0; i < noOfTriacs; i++)
    {
      if (!done)
      {
        if (triacState[i] == TRIAC_OFF)
        {
          nextStateOfTriac[i] = TRIAC_ON;
          cycleCountAtLastTransition = cycleCount;
          done = true;
        }
      }
    }
  }
}
 
byte decreaseLoadIfPossible()
{
  // if permitted by anti-flicker restrictions, turn off the highest valued
  // triac that is not already off.
  boolean done = false;
 
  if (cycleCount > cycleCountAtLastTransition + minCycleCountsBetweenTransitions)
  { 
    for (int i = (noOfTriacs -1); i >= 0; i--)
    {
      if (!done)
      {
        if (triacState[i] == TRIAC_ON)
        {
          nextStateOfTriac[i] = TRIAC_OFF;
          cycleCountAtLastTransition = cycleCount;
          done = true;
        }
      }
    }
  }
}
 
 

Tonight, I wanted to check how similar my power readings are with the CT in either direction.  Unfortunately, my latest build (Mk2i_rev3) won't run in 'tallymode', and I've yet to work out why.  Sorry about this, a corrected version will appear in due course.

The previous version, _rev2 is fine, and I've attached a couple of output files using that sketch to show how a 60W bulb is measured in each direction.  In each case, there are two runs, the first one being with no current flowing.  There does appear to be a Watt or so of offset between the two directions, perhaps there's something amiss with the calculations.  A rounding up or down error maybe? 

In today's sunshine, _rev2 heated our water very nicely in anti-flicker mode.  The LEDs were behaving as expected with the green one operating in anti-phase with the immersion heater's neon, and no blue or red interruptions.  After the thermostat had tripped, the blue one was fully on.  Then, later in the afternoon, after the sun had moved away, the red one was fully on. 

 I've used Red for underflow (pin 11), Blue for overflow (pin 12), and Green for surplusPV (pin 13) 

After chasing myself around in circles for a while, it finally dawned on me that my rev3 build had run out of RAM.  Too many print statements!  By heeding the advice at http://jeelabs.org/2011/05/22/atmega-memory-use/ , things soon fell into place and everything started to work properly again.

From that same article, I've lifted a routine which shows how much RAM is unused.  This is now called at three places in the code, the result being displayed each time to the Serial monitor.  One of these occasions is whenever the mode switch is changed, there being 24 bytes less at that time than during setup().  This seems an ideal place to check RAM availability because the processor is several levels up (down?) the stack by then.

In standard mode, I'm now seeing 'freeRam' values of around 1180 bytes;  this drops by exactly 600 when tallymode is enabled.  Some of this will be due to its 102-element array of 'long' tallies; the rest is consumed by various print statements and variables.  Tallymode can be made less RAM-hungry by simply reducing NUMBER_OF_TALLIES to something less than 100.  It was working fine today with just 5 of them while I was trying to figure out what was going on.

In the previous version, I disposed of a lot of global variables.  If they were only required by one function, but need to persist between calls, I made them static within the function that needed them.  Turns out that a 'long' variable consumes only 4 extra bytes if declared as a global, but 12 if declared as the only 'static' variable in a code block.

Sorry if all this is obvious to many.  I've not encountered the Arduino's RAM limitation before and it certainly does cause some headaches when things start going all wrong for no obvious reason.

It turns out that 'tallymode' has always had a rounding error of half a tally-step.  This has now been fixed in Mk2i_rev4, as attached, but it is still present in other versions.  This error affects +ve and -ve values equally so does not explain the 2W difference that I've noted when measuring a 60W bulb with the CT in different directions. 

PS. As posted, the anti-flicker settings in Mk2i_rev4 (as below) are intended for the test bench rather than for real.  The offset value below needs to be around 0.4 so that 80% of the bucket's capacity can be used.

// these settings are only used if anti-flicker mode is enabled
float minTimeBetweenActivationsinAFmode = 3;   // <-- anti-flicker requirement (seconds)
float offsetOfEnergyThresholdsInAFmode = 0.1; // <-- must not exceeed 0.5
 

I've just posted a video at: http://youtu.be/h_DrZHlstXk of the latest Mk2i build in action.  This uses a 3-phase meter to record the three flows of energy that are present: base-load and dump load in one direction, and simulated PV in the other.  The setup is more or less like this:

When adding an RFM12B module to my Arduino Uno, several pins that I've previously used for LEDs are no longer available.  Here is my proposed rearrangement.  All input welcome.

For Mk2i_rev4, with no RF:

0  - Serial Rx
1  - Serial Tx
2  - LED detector i/p (for polling)
3  - (spare)
4  - output mode selector i/p (normal / anti-flicker)
5  - (spare)
6  - (spare)
7  - (spare)
8  - (spare)
9  - trigger o/p
10 - led repeater o/p - not essential
11 - underflow LED o/p
12 - overflow LED o/p
13 - surplus PV LED o/p
 

For Mk2i_rev5, with RF module for remote load:

0  - Serial Rx
1  - Serial Tx
2  - RFM12B module (IRQ)
3  - LED detector i/p (for polling or interrupts)
4  - output mode selector i/p (normal v. anti-flicker)
5  - priority mode selector i/p (local v. remote)
6  - underflow LED o/p
7  - overflow LED o/p
8  - surplus PV LED o/p
9  - trigger o/p for local load
10 - RFM12B module (SEL)
11 - RFM12B module (SDI)
12 - RFM12B module (SDO)
13 - RFM12B module (CLK)

Never imagined I could use all of those pins!

There are two LED's that I consider essential. Which two doesn't matter but the function I use is this:

// **************************************************************************************
// The REDLED1 indicates when the energy bucket level is rising

        if ((availableEnergy - previousAvailableEnergy)>stepsize) // Check if level is rising
         digitalWrite(REDLED1,ON);
        else
         digitalWrite(REDLED1,OFF);

// REDLED2 indicates when the energy bucket level is falling

        if ((previousAvailableEnergy - availableEnergy)>stepsize) // Check if level is falling
         digitalWrite(REDLED2,ON);
        else
         digitalWrite(REDLED2,OFF);
 
// *************************************************************************************   

These make a very useful tool for testing as well as providing operational information at a glance.

My surplusPV_LED does much the same as this, but without the 'stepsize' criterion.  It just goes 'on' when the energy level is rising, and 'off' when it's falling, so tends to flicker when conditions are marginal.

There's a video of my RF link in action at: http://youtu.be/a1fngTaD4Iw.  The sketch that's supporting it is still in development, but if all goes to plan, Mk2i_rev5 will have:

- a new A/F algorithm which needs no calibration;

- selectable priority for the remote load;

- any number of dump loads;

- an associated sketch for the receiving end.

A long-standing bug at startup has also been fixed.

Here is rev_5 of my Mk2i PV Router.  There's a demo of it in action at: http://youtu.be/BHOTkBZLdig

The base-station hardware is a standard Arduino Uno with an RFM12B module attached as shown on the Building Blocks page.  In my garage rig, the input circuits are still on a breadboard but my indoor test rig setup is a bit tidier.  The remote end hardware is a sub-equipped emonTx with wires soldered to the four DIO ports for the LEDs.  Photos of each platform are attached.

Power is diverted using a new type of algorithm which has only one energy threshold.  It's similar in concept to the original on/off scheme but with the additional criterion that the triac may not switch within a specified period after the level has crossed the mid-point.  As posted, that period is 0.5 seconds.  This means that the logic is always homing in on the mid-point of the energy bucket rather than wandering away towards one end and then the other.  With a 3kW system, the energy state should always remain within the central 80% of the energy bucket, so there's effectively a 10% safety margin at either end.

This alternative scheme 'flicks' a little faster than the equivalent twin-threshold arrangement, but works really well when multiple loads are involved.  That's because there's more time for the logic to advance to the next lower priority load - decisions don't have to taken right at the edge of the meter's sweet zone when time is so critical.

Decisions about which loads should be on/off are taken on a logical basis with loads running from 0 to N-1.  A mapping is then performed between the physical and logical loads loads.  This stage takes into account the state of a front-panel switch, which allows the priorities of the local and remote loads can be reversed at run-time.  Any number of loads can be supported - if you can find the pins to run them from!

As posted, the rev_5 sketch will not run unless the RF module is present.  In the absence of this module, the flag RF_moduleIsAvailable must be set to false.   Similarly, the switches for output mode and priority selection will only work if runTimeSelectionIsEnabled to set to true. 

The receiver's logic is very straightforward.  If transmission is lost, the triac defaults to 'off'.  The receiver has a pair of LEDs to show whether transmission is OK or not, and there's a third LED to show the state of the remote load. 

As posted, the "transmission lost" period is set to 3.0 seconds, which is probably not a good choice with the refresh rate from the transmit side being once per second.  Something-and-a-bit seconds would be a better arrangement, then the receiver would abort after failing to detect a specified number of transmissions.

Any number of loads can be supported - if you can find the pins to run them from!

I've just put it on a Mega 2560- just need to find a few more loads now!

Hi Robin,

I've taken the plunge and loaded your new MK2i sketch but I can't get it to run. I've tried loading the MK2a again but that wont run either.

I've spent some time looking at your tools and the basic Arduino sketches. I know what the problem is and just wondered if you've seen it before.

If I use :-
int sampleI = analogRead(A5);
I can see the waveforms correctly.

But not when I use :-
byte voltageSensorPin = 2;
byte currentSensorPin = 1;
sampleI = analogRead(currentSensorPin);  
sampleV = analogRead(voltageSensorPin);
 

So it seems that my compiler wants the serial ports referenced by "A4 and  A5" and not "1 and 2".

Have you seen this before? Is there a setting I need to make within the Arduino compiler?

Thanks in advance, Keith

PS You're right, I'm enjoying playing with the sketches :-)

PPS More details of my problem can be found at http://www.talkingsolar.co.uk/index.php/forum/10-other-threads/1001-if-it-ain-t-broke-don-t-fix-it?limit=6&start=6#1022 but it only shows more details

(Robin is away on a course this week.)

The link between the numeric pin designations (0 - 5) and the alpha-numeric pin designations (A0 - A5) and their conversion to constants that eventually find their way to switching (I presume) the multiplexer input register is done in the header file pins_arduino.h (different versions according to your processor variant).

There's a macro at line 32 ('standard' version) that I guess has gone awry somehow - or maybe not! The macro does:

#define analogInputToDigitalPin(p)  ((p < 6) ? (p) + 14 : -1)

and a bit further down there is (inter alia):

static const uint8_t A1 = 15;
static const uint8_t A2 = 16;

so both end up as the same thing. I'm using Arduino V1.0.3 and it compiles quite happily for me with either

const byte voltageSensorPin = 2;  // analogue
const byte currentSensorPin = 1;   // analogue

or

const byte voltageSensorPin = A2;  // analogue
const byte currentSensorPin = A1;   // analogue

Out of interest, why did you choose to use A4 & A5 rather than A1 & A2? If you change the input pins that the sensors are wired to, the sketch has got to be wrong!

I suggest you change your code as you have done to suit your layout and leave it at that.

Hi Robert,

Thanks for your quick reply.

I bought a pre-built and preloaded setup from Trader9. I just used the pins he provided in the instructions that came with the parts.

So maybe all I need to do is change the input pins I use.

The Mk2i version of the sketch read the input in a different way.

ADMUX = 0x40 + currentSensorPin;
ADCSRA |= (1<<ADSC);

So I'm not sure I can change the the "currentSensorPin" to "A1".

I'll try changing the pins round tonight and see what happens. I've got a feeling that it will burst into life. Trader9 must have had a good reason to change the pins he used.

Thanks for your help, Keith

Robin's sketches obviously will only work with his circuit diagram, you can't expect otherwise.

The Mk2i version of the sketch read the input in a different way.

ADMUX = 0x40 + currentSensorPin;
ADCSRA |= (1<<ADSC);

At the top of the sketch, line 261 or thereabouts, it looks remarkably similar to me:

// analogue input pins:
const byte voltageSensorPin = 2;      // analogue
const byte currentSensorPin = 1;      // analogue

and that is where you change the input pin designations. The interrupt version is bypassing the time-consuming library routines and allowing the ADC to run freely in the background. You shouldn't need to touch the core interrupt code part that you quoted.

Hi Robert,

I'm now using the standard input pins and it's burst into life.

Thanks for you advice, Keith

I bought a pre-built and preloaded setup from Trader9. I just used the pins he provided in the instructions that came with the parts.

Sorry, I can't really comment on how anyone else may have re-packaged or modified my design elsewhere.  By following the guidance given here on this forum, everything about my Mk2 design should work as intended.  If it doesn't, please let me know.

As I recently posted on another OEM forum thread, "Robin's code" should work fine on any Atmega-based hardware platform that can measure V and I.  The two obvious contenders are:

a)  an Arduino Uno, with peripheral components as originally posted (for which Rich's PCB's are ideal)

b)  a standard emonTx with its associated AC/AC adaptor, plus output circuitry on strip-board or equivalent.

A friend is keen to have a PV diverter system like mine so I took round my demo box, plugged it in, and it worked straight away.  Here it is boiling up a 3kW kettle using only his free surplus power.

The system worked fine in 'normal' mode, but occasional pulses were seen at the meter when in A/F mode.  This was the first time that I've come across a meter which has a sweet zone of less than 1Wh.  The meter is an ACE 1000 with green and red LEDs.  When I reduced the value of the relevant timing parameter, postMidPointCrossingDelayForAF_cycles, from 25 to 10, it then worked fine in AF mode too albeit switching rather more quickly than one might like. 

The A/F algorithm in Mk2i Rev5 is different than in all previous builds.  It needs no calibration but doesn't give as much flicker suppression as the conventional twin-threshold one.  For a meter that has such a small window where a reciprocating power diverter can operate without penalty, it may be best for the standard A/F algorithm to be used.

Finally got time to adapt your MK2i_rev5 sketch to my hardware.   I take your point about lack of pins.  I have an Atmega128 waiting in the wings for my central control and monitoring node.   I plan to use ANTI_FLICKER mode so am not using that pin at runtime either.
I hit a brick wall with my RF24 (2.4ghz) radios so  put it on back burner and  switched development to another project (Measuring and displaying on LCD the solar charging  and discharge of my 900Ah SLA battery bank.)    I'm delighted you have tackled local/remote priority at runtime as this was on my list as well as  RF12 radio comms.  The RF12 jeelib library is excellent work.    I chose 433Mhz for several reasons but I have a dual band (144Mhz and 430 mhz) handheld transceiver so I can both monitor and legally generate interference as I am licensed to use this freq as a radio amateur.
I appreciate all the LED's at development time but I limited it to two LED outputs.  This is combined in a multicolored LED.  It flashes green on/off at 1 second intervals this being derived from the line
if ((cycleCount % 50) == 5)
This serves two purposes
1) it confirms the 50hz mains reference is connected and working
2) and that the unit is running at a glance. (ie not crashed).
The Red LED is derived from the inverse of surplusPV_LED showing when firing a tria.  I'm guessing that this will work for local or remote loads?
With your  preoccupation for not importing when unnecessary, my  prototype fires for 3 seconds at startup before settling.   Is this intentional.  I could investigate but thought I would as Robin first.
Development of my PCB has been scrapped as the JeeNode is an alternative.  I wasn't aware of it at the time and I was designing something quite similar but there is no point  when Jeelab has done such a good job with plenty of modules and the associated library.
MK2i_rev5 working and powering an oil filled electric radiator keeping me toasty in my lounge.  Gas powered central heating not fired up for many hours when sun is shining.

Laurence

I like the idea of the oil-filled radiator, Laurence.  We could do with one of those for when the DHW stat has tripped.

The startup problem that you mentioned has been fixed in Mk2i_PV_Router_rev5, and also in Mk2_PV_Router_mini_2. 

My first "proper" build was not at my own house (where my original breadboard continues to give good service - 7kWh today) but at a friend's house.  Pics attached.

The hardware is an emonTx, and the sketch is based on Mk2i_rev5.  The only change I've made is to replace the underflow and overflow LEDs by a pair which show when the local and remote loads are on.  No remote load is actually present, but the capability to drive it is clearly working.  The integral RF unit has been tested and found to be OK but is currently disabled.  If a display unit or RF-controlled secondary dump-load were ever to be required, it would just be a case of adding an aerial.

I've added an over-ride switch which forces the local load to come on via the triac.  This works using an OR function at the trigger's input.  By driving the opto-isolator from the 5V rail, there is plenty of headroom in which to squeeze a couple of diodes.  This prevents the Atmega's output pin from being held in the low state when the over-ride switch is operated. 

Hi All

Im on on my mission to deliver as much free energy as i can and so far been trying with Rev2 but to no avail, although many on this forum have helped

basic setup using Rich's PCB and a leonardo board

ive moved on to the Rev 4 after some recommendations to check out what is happening with "tallymode"

So far i have compiled, and uploaded the sketch, however i see nothing when i open the serial monitor - i suspect because of this taken from ardunios site

No reset when you open the serial port.
Unlike the Arduino Uno, the Leonardo and Micro won't restart your sketch when you open a serial port on the computer. That means you won't see serial data that's already been sent to the computer by the board, including, for example, most data sent in the setup() function.
This change means that if you're using any Serial print(), println() or write() statments in your setup, they won't show up when you open the serial monitor. To work around this, you can check to see if the serial port is open like so:

// while the serial stream is not open, do nothing:
   while (!Serial) ;

I am now thinking i should have just plumped for the UNO but i anyone cal tell me how to get the monitoring working for tallymode using Rev4 i would be most grateful

thanking you all in advance

I know nothing about the Leonardo, but if that's what they say, do it!

If you use the line you quote, the program will lock up there and loop indefinitely until serial comms is established, which probably isn't what you want. So you'll probably find it more convenient to invert the logic:

if (Serial) {
   Serial.print( .............);
   ....... any other serial statements etc
}

Therefore, I think you need to work through the sketch and wrap all the serial output statements like that - except of course setting up the serial comms to begin with still needs to be done: Serial.begin(9600);

Hi Robert

Thank you for the speedy reply, i did "have a go" but expertise is definitely not code !

Can you tell me if the following adaptation looks right

Original Code:

Serial.begin(9600);
  Serial.println();
  Serial.println();
  Serial.println();
  Serial.println("-------------------------------------");
  Serial.println("Sketch ID:      Mk2i_PV_Router_rev4.ino");

Amended code

Serial.begin(9600);
if (Serial) {
  Serial.println();
  Serial.println();
  Serial.println();
  Serial.println("-------------------------------------");
  Serial.println("Sketch ID:      Mk2i_PV_Router_rev4.ino");
}

many thanks

I will be most interested to see how this one develops. 

When I was installing an emonTx-based Mk2 Router recently, I had great difficulty in communicating with the board via the Serial interface.  I put it down to the 'Programmer' board which plugs onto the 6-pin header strip on the emonTx.  My laptop runs Windows XP.

Adding a 7 second wait at the very start of setup() seemed to help.  I then didn't miss the all important display info which appears during setup().  With a standard Uno, opening the Serial Monitor undoubtedly causes the sketch to restart which is very helpful.  With the emonTx plus programming adapter, I had to reload the program every time.  (I suppose I could have just unplugged the USB to interrupt its power supply.)

GTEC, With your modified code, the relevant display lines will simply be omitted if Serial is not yet up and working.  As this display only happens in one place, rather than in a loop, I don't think you can avoid waiting until Serial becomes available.  The

// while the serial stream is not open, do nothing:
   while (!Serial) ;

construct looks to be a neater way of what I've been doing to get by.

Rather than experiment with Mk2i_rev4 in Tallymode mode, why not try a lighter weight sketch such as RawSamplesTool?  It has a similar user-interface in that the program pauses at the end of each run until a user input is received.

What rae says is right - I hadn't looked at his sketch to check the details. So you do indeed need to sit in that while( ) until the serial is available.

But when you get down to code and print statements in loop( ), then you amended code looks right.

>The startup problem that you mentioned has been fixed in Mk2i_PV_Router_rev5,
I am using rev5 but still have a startup load firing for about 3 seconds.  I've just loaded this sketch as posted and only changed the pin to fire my triac in the code to
const byte physicalLoad_0_pin = 3;      // for trigger (active low)
I still get the startup firing.  The startup firing only started in MK2i_rev5.   previous version was MK2a_rev3.
I am not using a UNO but a breadboard with an Atmega328p and the rest of the hardware.

As regards GTEC's serial monitor: Do you get serial data if you press the reset button on the leonardo?
Briefly looking at the design of the leonardo, they reduced cost by having a single processor run your sketch AND perform serial comms.   Looks like you only get a reset when you press the reset button or upload a sketch..  I imagine your PC loses serial port when you do this in which case a delay at startup of sketch giving you enough time in the Arduino IDE to select the serial port and then open the serial monitor may be one way to work around the leonardo hardware limitation.  Like the following .  Substitute 20  (seconds) for the time you need.

void setup(void)
{
delay (20 * 1000);
Serial.begin(9600);
Serial.print("Did you catch this?");

Personally I haven't been "obsessed" with squeezing every last watt out of the system.  I've run most versions of Robins code and done very little calibration.  I looked at Phasecal and calibrated once for my system.  I then configured a Watts_Margin in an earlier version to make sure I was not importing.  I got to witinn 17 watts.  Close enough for a 4KW PV instalation.    I run a 20M twisted pair from the CT clamp at the moment.     I went contrary to many forum contributors thoughts by deriving the voltage reference from a separate winding in the same transformer as deriving the supply for the Atmega and hardware. 
I have plans to get a "sound card oscilloscope" working on my PC to look at the waveforms and phase shift of, and between the CT and AC Voltage sensor.   Just one of many projects in the pipeline.

Laurence

OK Laurence, I need to look again at what's happening at startup.  It may be that I've left something out.  Mk2i_Rev5 is more complex than earlier builds on account of it being able to support multiple loads.

I'm pretty sure that the triac no longer comes on at the start of Mk2_PV_Router_mini_2 (which is where I devised the fix) whereas it did for the initial version.  Maybe you could check this for me and PM the results. Thanks.

 Er - yes, there was a bug with the Mk2_PV_Router_mini_2 sketch.  My improved logic at startup was nearly right, I'd just omitted to force the triac to "off" within setup().  Being active low, it was 'on' by default during the 2-second start-up period.  A similar bug may be present in the latest Mk2i sketch, I'll check that next.

Mk2_PV_Router_mini_3, as attached, will hopefully work as intended.

And - er - yes, there was a similar bug in my Mk2i_rev5 sketch which was having an identical effect.  Within my revised startup sequence, although I had set all of the logical and physical loads to "OFF", I hadn't actually written that information to the relevant output pin.   So, just as with my mini_2 sketch, the output pin for the load was defaulting to '0' which was bringing the active-low trigger into the 'on' state.

Duly fixed as Mk2i_PV_Router_rev5a, as attached,

Thanks for bringing this to my attention Laurence, hopefully that's all the gremlins dealt with for now

Hi All

as my forte isn't code i am going back to basics and collecting an "UNO" tomorrow - that will eliminate some of the confusion that i have caused myself (i hope!)

FYI - I have previously run "RAw Data" and obtained results OK so i have to assume that it is something to do with the way in which the serial statements are used in the Rev4

When i start up serial monitor with the current setup (and using Win 7 Pro) i get no output at all, i can enter "g" and {cr} and i get the 3 different messages - "max Wats", "min watts" and "wait for X seconds"

Sadly at that stage it inevitably then freezes my laptoop completely - Ctrl-Alt-Del wont work so i have to do a hard shutdown, hence i cant post a screenshot i am afraid!

Laurence - i have done the same as you and used the "other side" of the ac-ac transformer to feed a full wave rectifier to then feed the board

All, i am exceptionally interested in the Rev 5 to control multiple loads as i have a complex heating system that could really benefit from this but im going to concentrate on getting Rev4 up and running first!

As a comment generally for all of these systems you will only get the maximum benefit if you heat the whole cylinder, most immersions (depending on length and cylinder position) will only heat the top third 

without having to add additional immersions, or adapt control strategies to heat multiple immersions, the easiest way to achieve this is to fit a "destratification" circulator (pump) to circulate the water from top to bottom

this is reasonably straightfroward and ill post some diagrams as soon as i can, but this would rely on a "constant on" output from one of teh pins to switch on a small relay to allow the pump to function ONLY when the immersion was being fed by the surplus energy

I have to assume (but i don't know) that this adaptation is a fairly simple addition to the sketch?

cheers

Griff

I have to assume (but i don't know) that this adaptation is a fairly simple addition to the sketch?

Yes, that logic is already present because the overflow LED comes on whenever the bucket reaches its upper limit.  You could just use this pin (active high) to control your relay.  When the stat closes and the immersion comes back on, the bucket would cease overflowing and the pump would go off.

If the amount of surplus power was insufficient to drive the pump continuously, then the pump would 'flicker' on and off just as the dump-load does.  Some additional logic to prevent this may be a good idea.

Laurence - i have done the same as you and used the "other side" of the ac-ac transformer to feed a full wave rectifier to then feed the board.

The complaint about doing this is based on the fact that a full wave rectifier followed up by a large smoothing capacitor draws a large current for a few milliseconds at each peak of the mains wave, which (allegedly) causes intolerable distortion and errors in your power measurement.

Three comments from me: the amount of distortion depends on the transformer impedance, so it may be insignificant anyway; it's the same for import or export, so in the Mk2 (any variant) the effect should be minimal; and finally if you have the voltage to spare, adding a series resistor to limit the inrush current to the smoothing capacitor will trade current for time and will reduce the amount of dip seen by the voltage monitor winding. (It extends the time the peak current flows because it starts lower down the peak of the wave, and may actually stop on the falling edge rather than exactly on the crest. The product of current and time, charge, has to be constant of course.)

When running an emonTx, the statement if (!Serial) never appears to return true.  So it seems that this trick won't help with the problem that I've been seeing, although it may with the Leonado.

Attached is an improved version of my MinAndMaxValues sketch which resets its data after a short run.  It now takes a break after every fifth sets of results so that the accumulated data can be more easily copied from the Serial window.  There is also a 7 second delay at the start of setup().

I've found at least 3 ways of getting this sketch to run on an emonTx so that all of the data is captured:

1.  Open the Serial window immediately that uploading is complete.  To restart the process you need to re-load the sketch :(

2. Disconnect the USB power, close the Serial window, re-instate the power, and then immediately open the Serial window again.  This saves re-loading the sketch, but does seem a bit hard on the USB connections :(

3.  Pull pin 1 of the Atmega chip low, this being its reset line :)

This latter approach would presumably work on any hardware platform. 

Whilst waiting to collect my Uno i got bored

so please see attached for a "Iphone" PSU now awaiting a capacitor for repair then it will fit nicely into my enclosure and should eliminate any of the distortion that is being spoken about

Robin, the logic you speak about would need to

1. Set a threshold limit of say 35W (pump dependant)

2. Only after that threshold was exceeded would it then pin out a constant "on" for one of the analogue pins

3. Only then  it would activate pin 9 proportional to the gross Wattage available less 35W (pump dependant) 

theres lots more that it could do to lessen the "parasitic" losses of the pump but you'd need feedback from the cylinder to achieve that sensibly

roll on tomorrow when i collect  my UNO !

GTEC: Robin, the logic you speak about would need to

1. Set a threshold limit of say 35W (pump dependant)

2. Only after that threshold was exceeded would it then pin out a constant "on" for one of the analogue pins

3. Only then  it would activate pin 9 proportional to the gross Wattage available less 35W (pump dependant) 

Once the bucket hits its overflow point, that usually means that the stat has opened, in which case your de-stratfication pump would need to come on.  It may take some minutes before the stat closes during which time surplus power could temporarily (or permanently, for the day) disappear.  For a variety of reasons, surplus power is rarely constant.  At this stage, what should you do? 

You could leave the pump on for a minimum of, say a minute (as "baseload"), but this may not be beneficial if it's near the end of the period of useful power for the day.  Or you could turn it off immediately in which case the pump would flicker.

Accounting for the pump's rated power consumption within the router's logic makes little sense to me.  If the pump needs to be on, then it simply forms part of the baseload, and surplus power is reduced accordingly. 

The sole role of my router has always been to divert surplus power.  Getting the router to turn something on when there is insufficient surplus power for that appliance is a step not to be taken lightly.

As I say, the logic itself is straightforward enough.  It's the underlying algorithm which is the tricky part.

Ok

Uno programmed and fitted

Success - well sort of

please see the report from tallymode attached, taken whilst i had a 1700W (approx) load connected

i suspect that something needs tweaking in the sketch here to obtain readings - am i right?

0, <- duration (secs)
0, <- no of values tallied

any ideas?

cheers

When the sketch is running correctly, the first question is the 'duration of run' one, and you should of course get the chance to enter it.  There is also a lengthy preamble to set the context.  If this doesn't happen, something is wrong with your serial comms link.

Tallymode was introduced in the initial post for my Mk2a sketch .  At that stage, I also posted a spreadsheet showing how the values could be nicely displayed on a spreadsheet, but I didn't post the actual results file.  The original results file is attached here.  The format is slightly different then as I was separating out the energy content into individual half-cycles rather than whole cycles, but the general file structure is essentially the same.

After the sketch has run, albeit for 0 seconds, and then spewed out some results, if you enter 'g', it will hopefully allow you to enter the complete set of instructions.

We now have a storage heater in place as our secondary dump-load, and it seems to be working nicely.  A video of the initial setup will soon be available at: http://youtu.be/TTgZxkW1sB8 (ETA 12:30 pm)

To keep the power rating below 3 kW, I've only fitted 3 of the 4 x 850W elements.  The attached photo shows this, with 4 of the 16 thermal bricks still be refitted. 

The RF side is working just as posted for Mk2i_rev5.  The remote unit's sketch is RF_for_Mk2_rx.ino, as stated on my Summary Page

Hi Robin et all, haven’t tried the Mk2i yet as happily flickering on the 1st revision of the Mk2 Sketch which by the way is working tremendous heating my 170 ltr Pressurised Direct hot water tank (Takes around 10 kw to heat it up fully). Yesterday received 15kwh from my 4kw SolarMax System so thanks to you, lovely free hot water. As a reminder to the community my install auto switch's from combi boiler to hot water storage when a given temperature is obtained from solar Emerson. Will try the anti flicker sketch's soon. Like the idea of the secondary dump going to storage heater had thoughts on the same line. Personally I would leave the 4 elements connected and take the chance that he mean current would be such that the fuse would not rupture. I have been switching 4kw for long periods and not had problems. That aside as mentioned when I first joined the community I was interested in a sketch that would accommodate say 3 or more Triacs fed direct from the pin outs of the Arduino. Each triac would sit in a pecking order whereby the bucket would switch all available surplus energy to the first Triac. If the bucket was to fill up with the first triac full on then the surplus would switch the second triac. If triacs 1 and 2 were to be full on any surplus at this point would switch the 3rd and so on. This way for example you could have a socket in the kitchen for boiling water/dumb coffee maker as highest priority with the second to an immersion and 3rd to a storage/oil heater may be. I realise this requires running separate T&E to a dedicated socket but I'm building at present so this is an easy one for me. In an effort to keep/use more or the solar energy I think this would be of great use to some of the forum members using their power to supplement the smaller indirect tank. Would really appreciate people’s views on this and other ideas, and Robin if you get time to modify a sketch to match. No pressure just a really nice to have sketch I reckon. Finally I'm also assuming this would make the sketch quite versatile as allowing single, dual or triple triac working, adding additional MOC/Triac hardware as required without having to modify the sketch when the hardware is added. BTW excellent video the Board is certainly not receiving feed in units today! Thx Dickie.

Hi Dickie, and thanks for the prompt feedback.  You'll no doubt be pleased to learn that Mk2i_rev5 already supports multiple loads: 

const byte noOfDumploads = 2; // The logic expects a minimum of 2 dumploads,
                              // for local & remote loads, but neither has to
                              // be physically present.

In my demo, I'm only using two loads (the 'local' one to heat our DHW, and the "remote" one for the storage heater via an RF link), but there is no limit as to how many loads the system can cope with.  The noOfDumploads variable is used to dimension various arrays which hold the necessary dumpload data.  It you're not using the RF module, there should be several spare pins, each of which can drive its own dedicated trigger & triac.

At this time of year, having multiple loads makes a lot of sense.  Our gas-powered CH still comes on at either end of the day so there's not much thermal capacity in the tank into which to dump surplus power.  A storage heater seemed the obvious way to go, and it started up straight away without any difficulty, as did my sketches.

Pity I can't build a decent power supply :(

Hello Robin,

I have built  a diverter using the mk2i rev4

I works great in normal mode.

However, after watching your anti-flicker video, you showed that the pulse is longer than the flicker version, however, when I  switch mine over to anti-flicker, the pulse is much longer, actually causing import before it switches off.

I have tried to calibrate the device, so I am guessing that is the problem.

Could you explain further who to calibrate the hardware.

Thanks

Terry

Hi Robin et All

Well it seems that i have success, many thanks to everyone that has held my hand throughout the process -

And a word to the beginner, if the spec says a "UNO" then use a UNO (i got caught out by a leonardo)

Picture of the final build attached, not as pretty as my original but note the power supply (Robin :)) that is a repaired Iphone charger in the top left of the enclosure

Final calibration to run and then its lid on!

Next is to drill out the enclosure lid to mount the four LED's and then look at a "destratification" pump and a secondary load (although i have 500L of store!)

happy days and thank you all again

cheers

Griff

Hi All

Firstly thank you all for all the work you guys have put in. My original design 2 years ago was a current switch and a relay so now I've finally got a solution platform that works effectively.

My PV however is 2 KW and it has always seemed a bit inappropriate to me to be pulsing 3KW loads when my surplus power is rarely going to be more that 1KW.  Plus without the Anti Flicker - I get plenty of it!

My tinking with the code has a halfwave solution working - albeit not perfectly.  I am only pulsing 1.5KW and the Flicker is hardly noticeable at all.  What I have done is to turn off the Triac after 10 samples have been taken at the end of the loop().

This works well most of the time but misses half cycles sometimes, which I think is because the fire request has gone out to the opto-isolator - but I am sending a Triac Off to it before it has actually come on.

If you guys don't consider my idea entirely crazy, (for us smaller PV installation people that is), can anyone think how else I should turn off the triac to ensure only a half cycle has occurred?

Paul   

I'm afraid you should not be using half cycles. Basically, it's illegal - not as such, but in doing so you generate even harmonics and the permitted limits for those are minuscule - you are allowed 1.08 A of second harmonic, 0.43 A of 4th and progressively smaller amounts of higher orders. And apart from that, it's antisocial because it puts a d.c. load on the supply transformers, and probably upsetting your inverter as well.

Hi

Have you checked the configuration of the immersion heater, you may (and i emphasise may) be able to alter its configuration so the load is less, alternatively (if it is that critical) a different immersion could be used that does allow this

Perhaps adding in a small RF controlled relay to bring in, or more importantly out, the elements of the immersion as and when desired so you still retain its full functionality when required?

Hope that this helps

paulbernardr: My PV however is 2 KW and it has always seemed a bit inappropriate to me to be pulsing 3KW loads when my surplus power is rarely going to be more that 1KW.  Plus without the Anti Flicker - I get plenty of it!

Paul, if dumping surplus power in whole-cycles bursts does not appeal to you, the easiest solution is surely just to use phase-angle control.  There's already a version of the Mk2 router which works in this way, the relevant entry in my Summary Page being:

Mk2_PV_phaseAngle.  A phase-angle controlled variant.  This requires a trigger which acts immediately rather than a zero-crossing one.    Originally posted, with full supporting information, on 01/11/12 at http://openenergymonitor.org/emon/node/841#comment-6990, this code is available at http://openenergymonitor.org/emon/sites/default/files/Mk2_PV_phaseAngle....

You just need to fit a different trigger device (i.e.  MOC3021 rather than MOC3041) and away you go.  Some precautions to limit the amount of generated EMC might be a good idea. 

With a more complex algorithm, you could no doubt arrange for surplus power to be distributed using half cycles whilst maintaining a overall DC balance.  I did spend some time working on this, but it seemed to involve a lot of complexity for very little benefit.  Operating a 3kW immersion in whole-cycles at the optimal AF rate for your meter is no different than repeatedly turning a standard kettle on & off every second or two.  Because each transition occurs at a zero-crossing point, there's minimal EMC and wear on the hardware.

terrywilk: ... after watching your anti-flicker video, you showed that the pulse is longer than the flicker version, however, when I  switch mine over to anti-flicker, the pulse is much longer, actually causing import before it switches off. ... I have tried to calibrate the device, so I am guessing that is the problem. ... Could you explain further who to calibrate the hardware.

OK, Terry, here goes:

I've written a lot about calibration in my various sketches, but it all seems rather dry & artificial.  So lets's go for a practical demo instead.  I've just put together a basic system that runs on an Arduino Uno and has a voltage sensor and a current sensor.  The CT is simply clipped around one core of an extension which supplies mains power to a test load.  The rig is just as in Section 8 of my Diverting Surplus PV Power article.  See the diagram entitled "A Suggested Test Rig for the Mk2 PV Router".  For the purpose of calibration, the output stage can be ignored; we're only interested in the measurement side.

OK, now we need a sketch.  Let's start with Mk2_PV_Router_mini_3.  This displays the net change of level of the energy bucket each second (but without the start-up bug that was in the _2 version).  We also need to supply an initial value of powerCal.  Let's go for 0.05. 

With no current running through the CT, I get values that are close to zero, as expected.  With a 40 W bulb, the values are around 27 W.  That suggests that my calibration is low by around 30%.  With a 2 kW heater, I'm seeing 1350 W, which appears to be similarly low, which is good. 

Now, we need to change powerCal by just the right amount to make our measured values of power match what we would expect.  To get from 1350W to 2000W, I need to increase powerCal by (2000 / 1350) = 1.48148.  So powerCal needs to be increased from 0.05 to 0.74074 or thereabouts.  Let's go for 0.074. 

Processing the 40 W bulb reading in a similar way, powerCal needs to be increased by (40 / 27).  This comes to exactly the same value, 1.48148.  How convenient, and entirely unexpected!

With powerCal = 0.074, we would expect 'spot-on' values.  In practice, my results with the same sketch were:

We're off!
12.63
0.01 << no load
0.24
-0.15
0.15
-0.00
-0.14
0.38
16.61 << 40W load
40.47
40.85
40.49
40.72
40.18
40.44
19.38  << no load
-0.15
0.05
-0.00
-0.04
0.09
1337.99  << 2 kW load
1971.77
1971.95
1970.83
1968.32
1962.58
582.35  << no load
-0.13
0.07
-0.05
-0.20
-0.24

So that looks pretty good to me.  The same powerCal parameter works equally well with all of my Mk2 sketches, so let's now try it with a more recent build which uses integer maths.  Mk2i_rev4 is a good candidate for this.  Although the energy bucket now uses different units, the sketch can still operate in a calibrated way.  For this, you need to be running in Tallymode.

So, I will now load up the Mk2i_rev4 sketch and set powerCal to 0.074.  PowerCal relates solely to the hardware that's in use, and nothing has changed there.  The first section of printout confirms that powerCal is set as expected:

Sketch ID:      Mk2i_PV_Router_rev4.ino
ADC mode:       125uS fixed timer
Output mode:    anti-flicker
  offsetOfEnergyThresholds  = 0.10
  minTimeBetweenActivations = 3.00s
Auto-select?:   yes
Extra Features: TALLYMODE
powerCal =      0.0740
phaseCal =      1.00
>>free RAM = 593
  capacityOfEnergyBucket_long = 2432432
  lowerEnergyThreshold_long   = 972972
  upperEnergyThreshold_long   = 1459459
  minCycleCountsBetweenActivations = 150
>>free RAM = 579
----

Tallymode setup:
Time to run (secs)? 

Now for the user responses.  Let's go for run time = 10 seconds;  min power = -100W; max power = 100W, and allow the run to complete while my 40W bulb is on.  The relevant part of the display is:

9, 0
47, 0
45, 1
43, 2
41, 134
39, 333
37, 28
35, 1
33, 0
31, 0
29, 0
2

With Mk2i, the first column is the power in Watts. The results show a definite grouping of data around the 40 Watt point, just as expected.   Repeating this operation for the 2KW heater, let's go for a min power of 1000W and a max power of 3000.  With the Uno, there's no need to re-start the program, just enter 'g' and [CR] ...

2060, 0
2020, 0
1980, 230
1940, 270
1900, 0
1860, 0

Wow, how's that for tight grouping of results!  Each of the 500 mains cycles has virtually the same amount of energy content.

So, by using a powerCal value of 0.074, my system is now nicely calibrated for calculating "real power", which is what the meter measures.  I can now be confident that a standard 2-level Anti-flicker scheme will work as intended.   With my Mk2i_rev4 code, as posted, the AF limits are at the 40% and 60% of the energy bucket.  Normally, one would go for, say, 10% and 90%, thereby using 80% of the available range.  This would be achieved by setting

float offsetOfEnergyThresholdsInAFmode = 0.4; // <-- must not exceeed 0.5

Note that Tallymode could have been used just as effectively to determine the correct value of powerCal for this rig.  If I were to set powerCal back to its original value of 0.05, the measured power values using Tallymode would be correspondingly lower.  So, with powerCal set to 0.05, here are the values for my 40W bulb and 2kW heater respectively:

30.50, 0
29.50, 0
28.50, 5
27.50, 102
26.50, 291
25.50, 96
24.50, 3
23.50, 0
22.50, 1

1390, 0
1370, 0
1350, 58
1330, 436
1310, 6
1290, 0

So that's 27W and 1350W, just as we saw with the other sketch.  QED

Hope that all makes sense!
 

Hi Robin

Just what i needed, thank you

ill be going home early today to set this up

cheers

Hi Robin,

Thank you very much for putting yourself out like this, I think this clears it all up.

This is a great forum for info and full of enterprising people like yourself.

One thing I would like clarified, I seem to remember a video of yours where you were using anti-flicker and you were surprised that it caused an LED event for import!

Did you manage to adjust anything on your rig to counter that event?

Until I fully investigate my calibration, I cannot reliably use anti-flicker at the moment, so fully utilising flicker mode with the annoyance of every time I open my fridge I see the flicker, but fully grinning from ear to ear that I am heating up my 220ltr tank for free.

I will be looking to try multiple loads soon but without RF as I have opted for a long control cable to the remote CU inside my house from the arduino output located in the meter cabinet outside my house approx 25mtrs away.

So is it possible to adapt / adjust the rev5 to not have to use RF?

Kind regards

Terry

Me, yesterday: Pity I can't build a decent power supply :(

The problem was with my choice of smoothing capacitor, as left over from some previous project.  10uF is OK for a small load, but is much too small when trying to power several LEDs at once.  With 100uF, it works fine, and a larger value would no doubt be even better for this task.

Here's my remote dump-load controller today sending surplus power to the storage heater.  The little flag is to stop eyes being poked out by the aerial. 

Unfortunately, unless there is a lot of surplus power during the daytime, our storage heater seems unlikely to get hot enough to really make much difference on chilly evenings.  But, as they say, (although I don't frequent the place myself), every little helps!

terrwilk:  Hi Robin, Thank you very much for putting yourself out like this, I think this clears it all up.

No problem, I should probably have done so a lot sooner.  Some of my written stuff about calibration does look a bit heavy now.  "Watts per ADC unit squared" takes some getting ones brain (and teeth!) around!

One thing I would like clarified, I seem to remember a video of yours where you were using anti-flicker and you were surprised that it caused an LED event for import! ... Did you manage to adjust anything on your rig to counter that event?

Yes, that did happen on one occasion.  I'll have to think a bit more about why that may have happened.  Dog walks are good for sorting these things out in one's mind ...

Until I fully investigate my calibration, I cannot reliably use anti-flicker at the moment,

Two suggestions:

1.  Reduce the gap between the upper and lower AF thresholds until your meter ceases to respond to each dump-cycle.  You'll then know that you're working within the "sweet zone" of your meter.  The actual calibration of your system then doesn't matter. 

2.  Use Mk2i_rev5, which doesn't require calibration.  As long as your dump-load doesn't exceed 3kW, and your meter is a standard 3600J one, the AF performance should be fine. 

I will be looking to try multiple loads soon but without RF as I have opted for a long control cable to the remote CU inside my house from the arduino output located in the meter cabinet outside my house approx 25mtrs away. ... So is it possible to adapt / adjust the rev5 to not have to use RF?

OK, that feature is already there in Mk2i_rev5, just make sure that   boolean RF_moduleIsAvailable = false;   You can then freely use the five digital pins that are otherwise tied up by the RF unit (Nos 2 and 10 - 13)

// ----------- Pinout assignments  -----------
//
// digital input pins:
// dig pin 0 is for Serial Rx
// dig pin 1 is for Serial Tx
// dig pin 2 is for the RFM12B module (IRQ)
const byte LED_detectorpin = 3; // for meter pulse detection (polling or interrupts)
const byte outputModeSelectorPin = 4;   //  for normal or anti-flicker mode
const byte loadPrioritySelectorPin = 5; //  local or remote load to have priority
const byte underflow_LED = 6;           // non-essential, may have to be axed.      
const byte overflow_LED = 7;      
const byte surplusPV_LED = 8;  
const byte physicalLoad_0_pin = 9;      // for trigger (active low)
// dig pin 10 is for the RFM12B module (SEL)
// dig pin 11 is for the RFM12B module (SDI)
// dig pin 12 is for the RFM12B module (SDO)
// dig pin 13 is for the RFM12B module (CLK)

Ok

So I didn't get away from work early, but i did mange to liberate (don't worry its my business) some bits to make a "Calibration extension lead"

FYI - for those with keen eyesight, the black flex is single core not twin or three core, double insulated 4mm conductor wired in series with the Line conductor feeding the socket outlet.

Roll on tomorrow when i will, no honestly i will, manage to calibrate and switch on...................

Cheers

When I first started this lark, I bought a cheapo multimeter from Maplin which featured a current clamp.  When compared with what a simple Uno can do along with a handful of standard components, its performance is absolute rubbish.   It can just about detect whether a couple of Amps is flowing or not, but that's all.  You could certainly not base any kind of a power router on it.

Hope your meter gives better results than mine!

Hi Robin,

I seem to be getting weird readings from my CT which is the 013-000 type using your recommendation of 33 ohms burden and I am using a 3KW immersion dump. Although the circuit I have seen has 150ohm burden.

Does playing with the value of the burden help with the calibration?

Terry

terrwilk: One thing I would like clarified, I seem to remember a video of yours where you were using anti-flicker and you were surprised that it caused an LED event for import! ... Did you manage to adjust anything on your rig to counter that event?

me: Yes, that did happen on one occasion.  I'll have to think a bit more about why that may have happened.  Dog walks are good for sorting these things out in one's mind ...

I've now located that event which can be seen at 6:25 on my IMGP9648.AVI video, posted on 27/5/12.   I'm pleased to report that that recording was taken some time before Mk2 came along :D

At that stage, I was using the standard calcVI() library routine along with an external AC power controller.  The main problem during that period was the slow overall response time.  As can be seen in that clip, the controller continued to dump power well after the conditions had changed.   When using any variant of my Mk2 Router, with our without AF measures in place, no such occurrences should be seen.  Mk2's response time is around 30 mS so the system can always react quickly to changing conditions, unless prevented from doing so by over-draconian AF measures.

With a nominally balanced Mk2 system, occasional chargeable events from the meter can never be prevented absolutely, this being an unavoidable consequence of the meter not telling us how its energy-flow readings are going - until its too late.   Any slight non-linearity of the router's measurement system (or the meter's for that matter) will result in the occasional slip, and a consequent recovery phase during which surplus energy will be lost.  This effect will be much more pronounced when an assertive AF regime is in place, i.e. one which attempts to use nearly all of the 'sweet zone' that the meter allows.
 

terrwilk: I seem to be getting weird readings from my CT which is the 013-000 type using your recommendation of 33 ohms burden and I am using a 3KW immersion dump. Although the circuit I have seen has 150ohm burden.

I've only recommended using a 150R burden, this being suitable for a system which only needs to measure up to +/- 3 kW.  A 33R burden will allow a greater overall range but with reduced resolution.  This could result in poorer performance at low power levels.

My advice to everyone is to please check the performance of their input sensors using the basic tools that I've posted.   My  RawSamplesTool_4ss_2 sketch allows three complete cycles' worth of V and I samples to be taken and displayed at full resolution via a spreadsheet.  This is the ideal playground to fine-tune your system for the job that you want it to do.

Aghhh

So got to calibration tonight..........................

Calibration appearedd to by way out (verified 2000W load showing up as 740+/-)

Altered powercal to 0.05 X 2.6 = 0.13

still a little bit out so altered it to 0.12 - my verified 2000W load now shows spot on 2000W - Fantastic

now to the lower scale - expecting good results, sadly disappointed, 40W lamp = 3W - hmmm

decided to check the system using "Raw data" and got the results in the attached

run and run again and no change, very odd

anyone any ideas, especially why the "countdown" appears to double count?

thank you in advance

With the countdown appearing like that, I don't think your voltage sensor is working properly. 

Do you get sensible values with my MinAndMaxValues tool?  Output values from the voltage sensor should be around 512 when no AC is applied, and then run from maybe 100 to 900 when the 240V is applied, but still be centred around the 512 mark.

Here are a couple of files showing typical results with AC voltage present and absent.  The sketch I used in both cases was RawSamplesTool.ino

Several people have contacted me recently about particular aspects of the Mk2 design.  Things like the ability to control multiple loads with or without an RF-link, the need for calibration, which hardware platform to use, etc.

As far as I can see, my Mk2i_PV_Router_rev5 sketch should meet most people's needs.  I'm currently using that version at home.  Surplus PV power is reliably diverted to our DHW tank until the stat opens, after which it goes to a storage heater.  The  control path for the second load is via an RF link, but does not need to be.  A pair of front-panel switches allow real-time selection of output mode (normal or AF) and priority selection (local or remote).  My build happens to be running on a Uno, but is running equally well on a nearby emonTX - only the control pin number needed to be changed.

Despite wording to the contrary in its preamble section, the above build will work fine without an RF module being present.  The relevant flag just needs to be set to false.  This incorrect wording, along with a minor start-up bug, has been fixed in version Mk2i_PV_Router_rev5a

Would like to ask a practical question: What happens when the boiler (dump load) maximum temperature is reached and dump load is switched off by boiler thermostat ?

I am really hesitant to connect a dump load without a thermostat and if there is a thermostat what happens then - would not like to push the excess PV generation back to grid as that requires a special agreement.

Rgds, PetriK

Petrik,

The PV Router can only divert surplus power while a dump load is available.  Once your thermostat opens, If no additional dump load is available, then surplus power will go back into the grid.  In the UK, although there is no agreement which prevents this, we would generally rather use our power rather than lose it.

My latest build, Mk2i_PV_Router_rev5a, can support several dump loads including one via an RF link.  I generally have my immersion heater as the primary dump, and a large storage heater as a secondary load.  Even on a very sunny day, I doubt whether our storage heater would ever reach its maximum temperature.  

Providing a back-up dump load that will never trip out should be fairly easy I would have thought.  Just find a large volume of water somewhere, and heat it!

Understood how it works, need a dump load if you dont want to leak excess generation back to grid. Now the puch line: how feasible do you see pushing the dump load to a battery cell that can be utilized during the night time ? The current algorithm allows easily to add resistive loads but store and forward energy  would benefit the consumer most. just a thought that what would be needed to change with the buckect systen if one wants to replace a dump load with a battery capacity for night  time ?

As long as the battery charger can tolerate being turned on and off at frequent intervals, there should be not problem (i.e. a simple transformer-rectifier lead-acid charger should be OK). But any other, particularly for the more modern battery types, Nickel or Lithium-based, would need to be checked with the manufacturer. Or you could think about designing your own charger where the charge rate was controlled by the bucket level!

RW: Or you could think about designing your own charger where the charge rate was controlled by the bucket level!

The phase-angle control version of my PV Router may be helpful for this.  With that version, surplus power is diverted proportionally rather than simply being 'on' or 'off'.  All the info about this, and the associated pitfalls with EMC, can be found via the link on my Summary Page (look for Mk2_PV_phaseAngle). 

Surplus power can, of course, still stop at any time.  Your logic would have to decide how best to react in this situation.

I can't imagine an intelligent charger taking kindly to being fed a chopped mains wave!

There are two approaches that I'd think about:
The battery charger could be made to be the primary dump load. The logic would require heavy modification to assure that it was switched as infrequently as possible. This implies that the secondary dump load would actually be used first and only when more than enough power was available to run the charger continuously would the charger be switched on and the secondary load used to trim the total load.
Alternatively, it should be possible to integrate the charger with the load controller so that it adjusted the charging rate within appropriate limits to suit the surplus power available. This means designing a charger.

RW: The battery charger could be made to be the primary dump load. The logic would require heavy modification to assure that it was switched as infrequently as possible. This implies that the secondary dump load would actually be used first and only when more than enough power was available to run the charger continuously would the charger be switched on and the secondary load used to trim the total load.

OK, so the primary load should only come on when there is sufficient power for it to be run continuously.  The problem with this arrangement is that the Mk2 Router has never had to deal with "power" before.  It doesn't have  "power meter"; it has an "energy bucket", just like the utility meter.

Because of the fickle nature of surplus power, it can never be guaranteed that the charger can be brought on "now" without needing to draw power from the grid within X seconds.  The logic could, however, make the decision to supply full power to the charger for a minimum of X seconds regardless of the amount of surplus power that is actually available.  This decision process could be regularly reviewed.  By this means, most of the power that's fed to the charger would be likely to be surplus, but not not all.

The most difficult condition would be when surplus power only just exceeds the rating of the charger, because any small reduction would cause the system to go into deficit.

As this is now interrupt based, maybe you dont need to empy the bucket fully, rather control pwm to dump load giving a constant output ? I see some benefit of a battery also during day time to buffer the energy making a secondary energy bucket. Tested this approach on my desktop with 1kwh package earlier this year with some decent efficiency. The switched loads like kettle, microwave etc are only used for minutes but do require more than my small panel setup can generate. I can also see in consumption data a peak of 1kw or so for such devices so secondary load could be reverted also additional capacity from a battery ? Now my setup has two GTI:s so dont know how to put this in practise for a more generic approach.

Petrik,  the purpose of my energy bucket is simply to match what the electricity meter does.  The meter keeps track of how much energy is flowing in either direction. but the result of this activity is only known when something is seen at the meter's LED, by which time it is too late to take any action.

By implementing a similar energy bucket whose level is known at all times, appropriate action can be taken so that a continuous balance is achieved between import and export.  By this means, no cost or penalties are registered against the user.

If you want to supply power to a battery charger which doesn't like being turned on and off, then that appliance is forming part of your base-load.  It is not acting a dump load.  A dump load needs to consume only power that is surplus.

Think of a reservoir which contains water.  When it rains, water flows in and the level rises.  When the level reaches its maximum, some water escapes via the overflow.  When the rain stops, so does the overflow.  If you wanted the overflow to continue running after the rain has stopped, you could no doubt arrange for this to happen by opening a valve at some lower level, but then it wouldn't be acting as an overflow any more.  It would be an output which provides water from the reservoir, which is different.

This is a little like the question I PM'ed you with recently Robin. Having heated the water using the pulsing triac, Switching over to another non resistive load would require a degree of hysteresis i.e. once the load is on it needs to be left on for say 10mins then a check to see if there is still enough solar to drive it, if there is leave the load on, if not turn it off for a set period then recheck. It would cause some unwanted import/export but in a controlled way.

Using a battery and inverter as storage looks elegant but charging the battery is going to be problematic as has been pointed out with anything other than good old solid 240V AC.

Ok - let me try to be a bit more specific. First must admit that have not studied mk2i well enough and answer may be found in the code already...

1) is it possible to make the mk2i energy bucket flow to dumb load using pwm rather than energy bursts? In this case the pwm output can be better used for charging either from mains or from directly from PV. Building a charger with pwm is fairly simple. Additional benefit may be reduced flickering and synchronization with mains sine wave. Trying to keep the bucket on suitable level by outputting pwm. .

2) depending a solar system it may be possible to connect battery directly to PV array to act an intermediate storage. My current plan is to ensure there is some capacity in boiler to heat it up. If temperature gets over a certain threshold then i just switch PV off or maybe to charge the battery for remaining capacity to be used during the evening and nights.

Petrik: Ok - let me try to be a bit more specific. First must admit that have not studied mk2i well enough and answer may be found in the code already...

And I will try to be specific also.  All Mk2 version work much the same, as does any other PV router.  There's nothing special about the way that Mk2i works, except that it's very fast!

An electricity meter only allows a small amount of energy to flow in the reverse direction before something unpleasant happens.  In the UK, we start to lose that energy and can't get it back without paying for it.  It other places, users are charged for any energy that they export.  

The job of the Router is therefore to ensure that no energy is exported.  It does this by diverting power to a dump load so that consumption matches generation.

The Router has three parts:

1.  The measurement system, which measures energy flow at the supply point

2.  The energy bucket, which accumulates the energy measurements

3.  The energy diversion system, which diverts surplus power to a dump load

When all of the above parts are working together, there is no net flow at the supply point.  

Parts 1. and 2. are entirely straightforward, they simply do their job.  Part 3. is different because there are different ways that surplus power can be diverted to the dump load.  In my original version, there was a single threshold, and the load was simply turned 'on' of 'off' depending on which side of the threshold it was.  That method works fine for heating water, but tends to make nearby lights flicker.

Flicker can be avoided by using phase-angle control.  That method adjusts the output rate (power) according to where the bucket's level is within its operating range. 

Whichever of the above methods are used, the energy bucket's level must always remain within the "sweet zone" of the meter.  To put it another way, power has to be consumed by the dump load at the same rate as which surplus power is being generated.

Providing that your dump load can be used in this way, that's fine.  Otherwise the Router will not be able to do its job properly.

Petrik:

Have you read Energy Meters?  It might help to explain why the Mk2 controller was designed the way it was.

Thanx chaps for education - I need to read the code in detail and then possibly revert.

Robin
I can confirm that the startup Triac on bug is fixed.
I designed a PCB with all the circuitry then came across JeeLabs Jeenode and jeelink etc.  I scrapped my design [no need to reinvent the wheel] and think I will design a plug in board incorporating the TX and RX end.  Only populate which end is needed or both if the local load is wired directly to immersion etc.   Think I'll be going their "HouseMon" RasberryPi web server route as I want to Store and display data such as Charge/Discharge of my 900Ah battery bank etc.  
I read on this forum that someone had added a HW Immersion Tank alongside a Combi Boiler.   I want to add a tank in parallel with my combi boiler so perhaps you can PM me if you read this.  [I have searched the forum and have been unable to find out who it was]
Laurence

Robin
I can confirm that the startup Triac on bug is fixed.

Thanks Laurence.  That will be with Mk2i_PV_Router_rev5a, as per our postings on the previous page (c. 14th April).

Robin
Been following the whole thread a while and awaiting my install of 3.7Kw PV. I have all parts to start building MK2i rev_5 (2 Adunio Uno's).  Whilst I have been into electronics over 40 years I have not done any coding for many years but your write up was good.

My main Uno will be near the consumer unit and I intend to run cat 5 twisted cable to the immersion tank (or you advise otherwise) where my output IC/triac will sit to control within a smaller aluminum box with heatsink . Would my output pin resistor on Uno be best placed in main output box or at main remote. Additionally I intend to install a 2nd output via RFM12B in main Uno and satellite Uno output unit to power a heater or other load.

What Im unsure of is that whilst I will have the neon pulsing/flickering on the Hot water tank and also on the remote heater, to see the output I not sure what will/can be availible on the main unit /remote main/ remote RF (e.g bucket LED's RF LEDs etc) as I am confused between RF LED's and Bucket LEDs in the various designs. Can you advise what I can have and where or a revised drawing would be great. Many thanks and really great project

Cheers Dave

Hi Dave,

Yes, Mk2i_rev5 should be fine for your needs. that's what we have running at home.  As posted, that sketch has LEDs for underflow and overflow.  In practice, I've not found them to be of much use, so I've generally re-allocated those LEDs to show when the local and remote LEDs are on/off.  If you look at the code, you should be able to see how to do this.  Whenever the local load is switched on or off, just switch your chosen LED at the same time; and similarly for the remote load.

With two loads and the RF unit in operation, digital pins are quickly used up.  If you don't want to switch between normal / anti-flicker mode, that's one digital pin you could save.  Similarly, if you don't want to select which load has the higher priority, then that's another pin that can be used for an LED.

The RF module uses 5 digital pins, and Tx and Rx take two more, so that's seven which are freely available for you to use.  It's really up to each constructor to decide how best their spare pins can be used. 

If you'd like to post a list of what functionality you'd like to see, I'd be more than happy to comment as to whether it can be done.  The answer is most likely to be 'Yes".  :)

And any unused analog pins can be used as digital pins too.

Hi All,

I've just moved over to Mk2i rev 5a in anti-flicker mode.

I have an Actaris Ace1000 meter which has a smaller sweet spot, so I've changed the bucket size to suit :-

#define JOULES_PER_WATT_HOUR 1250

But I've noticed another place in the sketch that has 3600j hard coded in.

energyAtLastOffTransition_long = 3600; // reset the 'opposite' mechanism.

Should this be changed to match the reduced size of the energy bucket? ie :-

energyAtLastOffTransition_long = JOULES_PER_WATT_HOUR;

Thanks in advance, Keith

To avoid any confusion later, I think it may be best to leave JOULES_PER_WATT_HOUR as 3600.

Mk2i_rev5 uses an alternative type of AF algorithm which has only one threshold and requires no calibration.  To tighten up its behaviour so that it will work with a meter that has a smaller 'sweet zone', you need to reduce the value of:

const int postMidPointCrossingDelayForAF_cycles = 25; // in 20 ms counts

If you set this value to 10, that should work fine with your meter.  A two-threshold algorithm, as used in Mk2i_rev4, will give a slower switching frequency.  If you want the multi-load capability of rev5, but the AF algorithm from rev4, you'll need to merge the relevant parts of the two sketches.  That shouldn't be too difficult, but it's not on my "to do" list at the moment.

Thanks Robin. I'll make those changes and see what happens.

GTEC: Robin, the logic you speak about would need to

1. Set a threshold limit of say 35W (pump dependant)

2. Only after that threshold was exceeded would it then pin out a constant "on" for one of the analogue pins

3. Only then  it would activate pin 9 proportional to the gross Wattage available less 35W (pump dependant) 

Once the bucket hits its overflow point, that usually means that the stat has opened, in which case your de-stratfication pump would need to come on.  It may take some minutes before the stat closes during which time surplus power could temporarily (or permanently, for the day) disappear.  For a variety of reasons, surplus power is rarely constant.  At this stage, what should you do? 

You could leave the pump on for a minimum of, say a minute (as "baseload"), but this may not be beneficial if it's near the end of the period of useful power for the day.  Or you could turn it off immediately in which case the pump would flicker.

Accounting for the pump's rated power consumption within the router's logic makes little sense to me.  If the pump needs to be on, then it simply forms part of the baseload, and surplus power is reduced accordingly. 

The sole role of my router has always been to divert surplus power.  Getting the router to turn something on when there is insufficient surplus power for that appliance is a step not to be taken lightly.

As I say, the logic itself is straightforward enough.  It's the underlying algorithm which is the tricky part.

A bit of feedback on this one.

I've just been running some test with a de-stratification pump on my store. The pump is powered from normal mains and switched on only when the router bucket is in overflow. I find that in practice the immersion stat closes within 20-30 seconds after the pump has started which re-starts power dumping and momentarily afterwards, the pump stops.

The logic is that the pump runs when the stat opens and there is still PV power. If the PV falls then the bucket will cease to overflow and the pump stops.

The worst case of the pump running when not needed would be when excess PV is available and the stat open long term which only occurs when the water in the tank both above and below the level of the immersion is up to temperature. At the end of the generation day or when PV is being consumed elsewhere in the house, the bucket will underflow and the pump will stop

No software changes involved, just a transistor driven by the overflow LED drive switching a relay suitable for the pump power.

So whilst the pump is not powered via the router as part of the dump load but it is almost certainly running on PV power. The balance of any PV does escape to the grid whilst the pump is on but we are possibly in the milli pence argument region here !

An even simpler method might be to connect the pump across the stat terminals. Now the router will be driving the pump with rapid on and off changes whenever the stat is open - I would only suggest this is tried with anti flicker enabled and it does still have the drawback that the triac is switching an inductive load albeit a small one and in series with the resistive  immersion element.

Bob

9fingers: The logic is that the pump runs when the stat opens and there is still PV power. If the PV falls then the bucket will cease to overflow and the pump stops.

OK, so your pump only comes on when the primary load cannot consume the surplus power that is available, which cause the bucket to overflow.  In that case, is simply acting as a secondary load.

My Mk2i_rev5 sketch already provides that functionality, but in a tidier way.  It doesn't need to rely on overflow which is an unsatisfactory way to do it, IMHO.  The measurement system is linear throughout the energy bucket's range, but ceases to be so at either end. 

All functionality should therefore be constrained to take place within the linear zone.  Difficulties can occur when switching between different loads, which is essentially what's happening here.  The ower-diversion algorithm that is used in my rev5 code appears to work better in this regard than previous AF algorithms. 

In your case, my Rev5 logic would detect when your heater is unable to prevent the bucket's level from rising (because the stat has opened), and would bring the pump on.  This would occur well before the overflow point is reached thereby preventing your system from leaving the linear region.

Fair enough Robin. I mainly responded to comment on how quickly my stat reacted to the pump being on - which was the question raised in the earlier post. I then got carried away with describing the rest of my set up which is firmly rev4 based and working well for my needs.

Cheers

Bob

OK, Bob, thanks for the clarification. 

A de-stratification pump makes a lot of sense to me, and it's good to know how quickly it can do its job.  On many occasions, I've run off some hot water for a useful purpose but been unsuccessful in bringing the stat back on.  Until the whole tank is fully up to temperature, a de-strat pump should always be able to encourage a greater take-up of heat. 

If the pump were ever to be on for longer than a certain period, then some refinement to the algorithm could no doubt be devised to turn it off.  Otherwise it could remain 'on' for hours at a time during sunny weather when the house is unoccupied.

A 'bottom' thermostat perhaps? When the bottom of the tank is hot, there's no further need for the pump.

I've been quite surprised how small the temperature gradient is above the heat source.

My store is 2m tall and 500mm diameter and I'm dumping into a horizontal immersion about 300mm up from the bottom (there is one higher up as well which I might play with later).

I've had 7 temperature measurement ports fitted as they were so cheap at manufacture. These are fairly evenly distributed vertically up the cylinder and I see little more than a few degrees difference between them. Obviously lots of internal convection going on.

It seems that the only use for the de-strat pump on my tank seems to be to heat the water below the level of the heat source to cram in the very last little bit of energy into the store which is about the 15%.

What this does mean though is that when I have less PV available to dump, I could use the upper immersion to get the upper half of the tank hot first and then decide how to use remaining PV later in the day either to switch over to the lower immersion or to use the de-strat pump.

Plenty of scope for experimentation coming up!

Bob

That makes sense to me. Natural convection is doing the stirring for you. A hypothesis: It might be that the area of the heater in the horizontal plane has a lot to do with it. If it's relatively compact (viz. the element reaches in from the top) there is less stirring from convection than if it reaches in from the side. Maybe this is an experiment to include? - not full size of course, I'm thinking in terms of a small power resistor in a clear plastic bottle fed from 6 V or so!

If you have more than one immersion, it makes a good sense to dump surplus power into the upper one first.  The lower one can then simply act as the secondary load.  No need for any pumps, the Mk2i_rev5 code will deal with multiple dump-loads as posted.  A de-strat pump could also be fitted as the third load, but maybe that's going a bit OTT (or UTB!)

(Incidentally, I had occasion to run Mk2i_rev5a today, and the triac does indeed remain off during initialisation - Phew!)

In the short term, I'm without a boiler connection to the new store. I'm using the lower heater as the dump with the stat set to maximum (80C) and the upper immersion is set to 60C on a timeswitch at 5pm for an hour or so  to cover days when there is insufficient solarPV  to get the store up to 60C. The recent degradation in the weather compared to the last week or so of 20kWh/day of PV may well mean the upper immersion will come into play.

I've ordered the boiler today for fitting over the summer and that will connect to the store. At some stage this year I'll fit the evacuated tubes on the roof after which both immersion heaters will be available for 'playing' with dumping/de-strat schemes with both solar thermal and PV as inputs.

Previous experience with near vertical immersions also seemed to support/promote good convection currents when new however it did seem that after significant scaling, the thermostat would be satisified by a relatively small amount of very hot water at the top (well over the nominal stat setting) and the rest somewhat cooler. As the stat operation is simply a function of the length of the sensor overall, this can be satisfied in a number of combination of layers of different temperature water.

At one stage years ago I had to fit a de-strat pump in order to get a decent amount of water at a sensible temperature. When the element eventually failed due to hard water corrosion, a new clean one went back to behaving properly and the pump was no longer needed.

Apologies for digression from the main topic!

Bob

No problem.  Maybe this topic could be continued on the   The PV Energy Dump and How To Use It   thread.

Having already built one of these units for a friend I am looking to build another, but with the addition of a storage heater.

Is it possible to build a MK2 system with 2 or 3 loads, but without the wireless option?

I can easily hard wire the loads to the control box but was not sure if the code is written for direct control option or wireless only.

Yes, Mk2_rev5 will work for any number of dump-loads, the only limitation being that you need an output pin to drive each one.  If you're not using the RF module, then several extra pins become available.  I gather than the analog pins can be used as digital outputs too. 

With Mk2i_rev5 (or preferably the _rev5a version), just set the number of dump-loads to be as you wish.  All the arrays for the logical and physical loads with then be re-dimensioned automatically.  Apart from assigning a driver pin for each load, there should be very little that you'll need to change in the code.

Maybe we should hold a competition to see who can construct a PV Router system with the most loads :)

HI All

after a little "Time away" (no not prison) I can proudly report that with the support of Calypso rae i managed to get my Mk2i version up and running - keen to move on now and a "functional" issue that i have seen is how the rest of my family now understand the system (yes i'm being poilte)

Can anyone suggest a piece of code that can be integrated into Calypso's sketches that would, when a momentary switch is pressed, set pin 9 to high for 60 minutes (thus putting the Triac on permanently) and output to an LED until the 60 minutes has elapsed, in addition if the momentary switch is pressed whilst pin 9 is high then it switches it to low (off)

This way i can mount a very small momentary switch to the side of my enclosure and this will ensure that when the family need hot water boosting they don't get confused as to how to use (and switch off!) the existing arrangement that s a 20A DP switch that bypasses the input and output terminals of the Triac and switches the power onto the immersion manually

any suggestions welcome

cheers

Can you find two free digital pins?  If so, that feature should be straightforward enough to implement. 

Rather than relying on millis(), I would use the fact that one hour is 60 x 60 x 50 = 180,000 mains cycles.  There is already 'long' variable which counts mains cycles, it being cycleCount.  So you could record this value when the 'on' button is pressed, and then turn the triac off when cycleCount has advanced by another 180,000. 

An tidier approach might be to define another 'long' variable, such as overrideTimerCount, and to increment this variable at the same time as cycleCount.  When the 'on' button is pressed, a boolean flag such as overrideOn could be set to true, and overrideTimerCount reset to 0.  At the start of each new mains cycle, overrideTimerCount would be incremented and would be found to be less than its maximum value, which is overrideTimerMaxCount = 60 x 60 x 50 = 180,000.  Eventually the value of overrideTimerCount would be found to be equal to its max value, whereupon the overrideOn flag would be set to false.  If overrideTimerCount is only checked/incremented when overrideOn is true, then there will be no complications with overflow. 

If the 'off' button is pressed, then overrideOn would just be set to false.  Whenever overrideOn is true, triacState should be set to true, regardless of the state of the energy bucket.  This will force the immersion heater to come on.

To avoid switch bounce, you could replicate the code that's already in Mk2i_rev5a for the existing two switches.  Each of the new switches would go straight to ground, and you would need to activate the internal pullup for each pin within setup().

For the "immersion on" LED, maybe you could re-allocate one of the "underflow" and "overflow" ones which are a bit techie!

If you're still stuck in a few days time, just let me know which version of the code you're using, and which pins are free, and I'll put together some code for you.  It sounds to be a useful upgrade.

Hi

thank you for that

ill have a play with a spare board that i have tomorrow and let you know how i get on, but as you know my knowledge of code is poor at best

cheers

If I were doing this, I would take a version of the code that I want to use (e.g. Mk21_rev5a) and chop it down to the bare minimum.  It just needs to detect and count mains cycles.

Then I would declare the new software components and get the new functionality to work.  Once it's all working nicely, the various new parts can be carefully copied across to your target file.  A file-comparison utility may be useful, I use Kdiff3

Prior to this, I would probably run simple sketch which just reads the value of each switch, and drives an LED.  Then the hardware is known to be working.  I posted a sketch of this type recently, I think it's called IO_checker.ino, so it's probably at

http://openenergymonitor.org/emon/sites/default/files/IO_checker.ino_.zip

Contrary to my post saying I wouldn't be able to supply the triac boards on their own I will now be able to supply kits for the O/P board with all components for £15 plus £1 P&P, please PM me if interested.

Rich.

Robin, could you please ellaborate how tio handle voltageCal on continental europe where VAC is centered around 230 rather than 240. I dont see this very critical as it looks to be used only as triggering threshold but anyway from documentation point of view maybe a clarification could be used.

VOLTAGECAL = (float)679 / 471; // Units are Volts per ADC-level.
                        // This value is used to determine when the voltage level is suitable for
                        // arming the external trigger device.  To set this value, note the min and max
                        // numbers that are seen when measuring 240Vac via the voltage sensor, which
                        // is 678.8V p-t-p.  The range on my setup is 471 meaning that I'm under-reading
                        // voltage by 471/679.  VOLTAGECAL therefore need to be the inverse of this, i.e.
                        // 679/471 or 1.44

VoltageCal is only used to determine a suitable moment on the voltage waveform to arm the trigger.  As long as the trigger is armed at some time after the voltage has dropped below 20V, the system will work fine. 

An alternative approach is to simply delay arming the trigger until, say, the 3rd consecutive sample when polarityNow is negative.   Then there is no need to use voltageCal at all.   I've tried this scheme and it does work, but I can't remember whether I've ever released that code.

My Mk2 design is only interested in Real Power, so I've only provided a powerCal parameter.  This seemed a better arrangement than calibrating voltage and current independently.  

As I've said on many occasions, my Mk2 PV Router does not need to be calibrated.  To achieve a balance between import and export, the measurement system just needs to be linear.

Just studynig the code at spare time and noticed that only imperial voltage references are used which can be confusing without reading the code more in detail ;-)

Maybe next I want to figure out possibilities of implementing to Mk2i this old safety margin... but now capacity is 3600J * 50 * (1/powerCal) and cyclesPerSecond does not exist anymore as its interrupts based.

        // Reduce the level in the energy bucket by the specified safety margin.
        // This allows the system to be positively biassed towards export or import
        energyInBucket -= safetyMargin_watts / cyclesPerSecond;

Hmmm...

I removed the safety margin from later Mk2 versions because it did not seem to be serving any useful purpose.  The balance that can be achieved by a Mk2 PV Router is well within the anti-creep limit of most digital meters.  While the meter's LED remains on, then you are clearly not being charged for any imported power.  Users in Spain would presumably not wish to introduce a bias towards export because exported power is chargeable.

Analogue meters don't seem to behave well when the current starts and stops rapidly.  This effect can be seen on various videos that I've posted.  If you have such a meter, and notice a small amount of forward creep while the system is nominally balanced, then you may wish to re-introduce the safety margin. 

With integer maths, the energy bucket is no longer calibrated in Joules.  But with a bit of thought, you should be able to work out how much to decrement it by every mains cycle.  The numerical capacity of the 1 WattHour bucket is determined and displayed to the Serial Monitor during the setup() routine. 

I removed the safety margin from later Mk2 versions because it did not seem to be serving any useful purpose.  The balance that can be achieved by a Mk2 PV Router is well within the anti-creep limit of most digital meters.  While the meter's LED remains on, then you are clearly not being charged for any imported power.  Users in Spain would presumably not wish to introduce a bias towards export because exported power is chargeable.

Yes, think have heard this already - anyhow for testing purposes a constant load that can be seen on a standard plugin electricity meter would be a reason to have this. Normal plugin type electricity meters do not show negative values. (Of course difficult to say what is the bucket size for a plugin meter and if there are other )

About powerCal, I guess its just the PV power (less inverter inefficiency) that counts. With PV systems of couple of hundreds of Watts dont see any reason to have more than 1kw range and then ensure with some clamping zeners that voltage does not get over 3V. This anyhow made me think about emonTX design: If sensitivity is changed with a burden then the clamping must happen just before the AD input pin ?

About powerCal, I guess its just the PV power (less inverter inefficiency) that counts. 

No.  The Mk2 PV Router measures the net flow of energy (i.e. surplus power) at the supply point.  This is the difference between the power that is being consumed and generated on your premises.  The generated value is what comes out of your inverter - the efficiency of the inverter is not relevant to the calculation.

powerCal is the ratio between "real power" and the value that's calculated by the measurement system.  To find the actual amount of surplus real power, you take the calculated value and multiply it by powerCal. 

An alternative approach might be to measure your consumption and generation values separately, and then calculate their difference in order to quantify any surplus power.  This is how the OEM Solar Monitor system works.  But when the sole purpose of the equipment is to divert surplus power, I think it's best to measure in just one place, next to the meter.  That's why the Mk2 PV Router works in this way.

Ahh - I was talking in the context of CT resolution need. If the purpose is to avoid pushing excess energy to the grid then the AD resolution maybe should be calculated based on PV generation to maximize operation? In opposite case the bucket is well empty before ? For testing this low power level accuracy also a reintroduction of safety margin could be beneficial.

Sorry, Petrik, I'm not sure what point you're making.  The measurement system needs to be scaled so as to record correctly the net flow of energy under all situations while power is being diverted.  This means the greater of the PV rating and the dump-load rating.   If you have a 2 kW PV system and a 3 kW dump-load, it's important that the system can measure 3 kW without hitting the limits of the ADC.  Otherwise there will be problems when surplus power is at a minimum.

My comments about voltageCal yesterday were not correct.  Although the triac comes on at the -ve going zero-crossing point, the trigger needs to be armed within the +ve half of the preceeding cycle.  The only requirement is that this must not occur until the voltage is at least 20V beyond the z/c point.

In Mk2i_rev5a, the trigger is armed when:    if(sampleVminusDC_long > triggerThreshold_long)  is true.

This line could safely be replaced by:

if(samplesDuringThisCycle == 3)    

The number 3 is not important.  Anything between 2 and 20 will be fine.  The number 1 would sometimes not work because the voltage would not yet be 20V beyond the z/c point.  Having replaced this line as above, voltageCal can be safely removed.

The same measure could be usefully applied to earlier Mk2 builds.  In Mk2_PV_Router_mini_3.ino, the line

        if((sampleVminusDC * VOLTAGECAL) > 30) // 20V min for Motorola trigger

could simply be replaced by

if(samplesDuringThisCycle == 3)
 

Let me try with practical info about burden for scaling AD. My PV is 1kwp, burden load is 1kw, baseline, average loads during daytime vary between 250-750w and maximum ever noticed is 8kw when heating, washing machine and water boiler are on. All this on one phase. Stock emonTx CT burden resistor is scaled for 50A where as the feeling would say that 16A optimized burden resistor for CT ould be plenty with three times more resolution. (just thinking aloud while putting the next test rig together.)

Remember that a current transformer is a current source, and if you increase your burden resistor beyond the VA rating of the c.t., you will overload it with a dramatic increase in phase and amplitude errors. You need to faithfully capture the waveform at the peak current in either direction while your dump load is operating; otherwise you will not measure the power flow accurately and the router will not be able to achieve a perfect balance.

The way I understand this isthat after 3600j the bucket is empty when energy is flowing to the grid. To reach the balance in my case a bit over 1kw would do. After that phase and amplitude errors do not really matter as all I need to know that I am exporting to the grid (and bucket is empty). What matters is resolution betweekn -1kw to +1kw.. What am I thinking incorrectly ?

When the bucket is empty, or when the bucket is overflowing, the router is no longer in control and accuracy and linearity are unimportant.  In between, when the router is in control, energy flow into and out of the bucket is balanced - energy, the product of power and time, is balanced but the power and hence the current in each direction might be vastly different. It is those currents that must be accurately measured. If your dump load is 1 kW, then a linear range that is a little over 1 kW should be enough - but you must protect your inputs against overvoltage in the event of a fault downstream of the c.t. that could cause a very high transient voltage to appear on the output of the c.t.  (That is because when the c.t. is saturating, the flux remains approximately constant for a large part of each half cycle, then changes rapidly as the current switches polarity, and secondary voltage is proportional to the rate of change of flux.)

This may be of use to Leonardo users,

I have just found the issue after a few frustrating hours trying to change from the original Mk2 software, and now have the Mk2i fully functioning.

after trawling through the code I found the Analogue pins at low level are mapped differently compared with the UNOs

A1= ADC1 on the Uno and =ADC6 on the Leonardo

A2= ADC2 on the Uno and =ADC5 on the Leonardo

Just altered the pin assignments and hey presto!

perhaps the code comments could refer to the ADC numbering rather than physical pin numbers?

-no issues with print statements although I put a 10 sec start delay if I want to use the serial monitor.

The build instructions specifically state "Arduino Uno". If you use a different platform, or divert from the original design in any other way, it is up to you to check that you have modified the design of both hardware and software accordingly.

Thanks for clarifying the burden/resolution question.

Just came off from phone with the local electricity provider. He said that our new three phase electricity meter takes a sum of each of the phases so if one is generating and two is consuming then meter sees a sum of these three elements together. This is a good thing but creates some gray hair how to utilize this with mk2i which has been designed as one phase system only ? Any comments ?

Yes, we know that at least some 3-phase meters work that way (see the Energy Meters article in Building Blocks). I believe MartinR is using, and Noah is thinking of using, a 3-phase router, but I have no details other than what you might find elsewhere in these forums.  Robin designed the Mk 2 as a single phase system because like almost every other home in the UK, he only has a single phase supply.

In terms of a solution, MartinR's 3 stacked emonTx's is clearly a neat solution and allows a fast sample rate on each phase (which could be a problem with trying to read all 3 phases with one ATmega328). The "energy bucket" needs to receive contributions from all 3 phases, it should work with only one dump load - presumably connected to the phase that is most lightly loaded - but it might be possible to have a smaller dump load on each phase and use them together or in any combination.

Robin is away on a training course for 2 weeks, I expect he will comment on his return. When you discover the size of the "Energy Bucket" of your meter, let me know and I will add the details to the Energy Meters page.

Some details on my 3-phase system...

As Robert said, I have 3 stacked emonTXs, connected via I2C interface. They each calculate the energy per cycle for one phase. One emonTX is designated as master and it requests the cycle energy for the other 2 phases at the end of its own cycle. The 3 energy values are added to the energy bucket and from that point on it behaves just like a single phase system.

One complication is that you can't just add the raw, unscaled data into the energy bucket as you can for a single-phase system since the scale, or calibration, will be different for each phase, you have to equalise them first.

On the output side, it doesn't matter which phase your dump load(s) is/are on since they all affect the energy bucket in the same way. I heat up my 3 immersion heaters in turn and then pump any excess into my floor heating. For the latter I dump into each phase in turn as this reduces the flicker frequency by a factor of 3.

Maybe 3 phase system does not need to be exact. I dont mind if there is some energy consumption from the grid but when the kettle or microwave is on on phase 2 while phase 1 shows excess there is no reason to shoot the energy to the dump load hot water tank. Maybe the easiest solution would be just adding the two other phases as safety margin was there earlier ? This way one emontx with one transformer and three CT:s could work close enough. Adding two more emontx and related ct:s and teansformers is too much, in my cabinet there is already 2 emontx:s + nanoderf stacked ;-) thos just before adding robins mk2i. 

"when the kettle or microwave is on on phase 2 while phase 1 shows excess there is no reason to shoot the energy to the dump load hot water tank."

If the three phases all contribute to the "energy bucket", then that will not happen. The load can be connected to any phase and it will be controlled by the overall energy flow.

"one emontx with one transformer and three CT:s"

If the voltages on the three phases are always accurately balanced, then again 3 c.t's (and using one real voltage and delaying it twice for the other two phases) might give results that are 'good enough'.

;-) of course voltages are not always the same as load is not balanced in a normal household, anyhow what i recall from measuring we are talking about 1-3volt differences which means 1% avg - not really significant.

If your supply is that good you should get some reasonable results. Here, out in the sticks in the UK, I regularly see more than 10V difference between phases so more error than I'm happy with.

You'd be best off using an emonTx for the solar diversion as it already has the 3 CT inputs and it could probably just be one of the emonTxs you already have so would save some space if that is an issue.

This would be a good application for a phase-locked loop since if you chose the samples per cycle to be a multiple of 3, say 48 (which is just possible with 3 CTs) then you could estimate the voltages of the other phases simply by using the 17th and 33rd samples as the first sample for phases 2 and 3 respectively. You wouldn't need to save and replay the waveform as emonTx_CT123_3Phase_Voltage does.

"You wouldn't need to save and replay the waveform as emonTx_CT123_3Phase_Voltage does."

In that respect, how is a PLL different to the standard unsynchronised emonlib. Can you explain that?

(I don't think Petrik has a particularly solid supply, isn't it just that he is very lightly loading it with only 1 kW max load? If it's 3 V dip with 8 kW load, that's a different matter - but still not all that solid, about 600 kVA fault level. Robin's Mk 2 can measure the supply fault level, and so can yours, of course.)

Can you explain that?

No I can't :) Note to self: don't make posts on your way out in the morning without thinking them through first!

Obviously you'd still need to know what the voltage had been at the same point in the measured waveform so you would still have to save at least 32 samples. There might be some benefit that you'd more accurately know the phase of each sample but I'm clutching at straws here.

Local national gris code says the voltage must be all the time between 195-253V but in reality when living around 3 miles from local powerplant havent seen anything else than between 227-233. Havent really monitored this but recall from apc ups datalogs. Maximum load in this house is around 8kw per phase which i have seen on emonglc totalling up to around 13kw. The big loads are more or less symmetric here like 3phase boiler and central heating, very seldom 1 phase devices exept in remote cottages. Grid has been built bearing in mind the heating needs of a -30C winter day when everyone is cooking turkey in oven. 

MartinR:

[Been there, done that ]  But as you have correctly identified, the PLL with the number of samples an exact multiple of 3 does have a number of advantages, not the least being that given identical c.t's, PHASECAL should be the same for all 3 channels (though there will still be a current-dependent phase shift that you can do very little about) and that means that the phase correction can be applied once before the samples are stored, which should help with the processor load.

Petrik:

If your supply is well balanced, then Martin's suggestion of 1 emonTx with 3 c.t's; and in the sketch merge the arrays out of emonTx_CT123_3Phase_Voltage into his (or Robin's) PLL sketch with the energy from all 3 phases feeding into the one energy bucket does seem to be the most economical solution.

Hi All

I've been away again and I'm afraid that i got distracted by wanting to know what was going on in my Hot water store (a 500 Litre stratified store) and i got hooked on the actual monitoring side of things - please see this link 

https://xively.com/feeds/126629 

The sensors (DS18B20) are mounted at the top (Temperature 1), then 350 mm intervals to the bottom of the tank (Temperature 5)

You can readily see what is going on and when the immersion kicks in so it makes for interesting reading 

I'll be refocusing on the Mk2i next weekend and getting some data out of that one as well (if i can) 

Thanks to everyone for a fantastic website and loads of help and good ideas that have come from it

Cheers 

Griff Thomas

Hi Griff,

Your link doesn't work for me.  It's starts with https://  Is it a logged in user account?

Cheers, Keith

The link works for me (now?).

Griff: You might not have seen these threads:  External immersion heaters and How about energy storage  There could be some ideas there for you.

Hi Griff,

I've something similar on my store. 7 sensors vertically up the tank and one on cold input and another on mixed DHW out.

From that I can calculate an approximate volume of useful DHW at the tap and display that at various locations. Nothing online yet - that is work in progress.

Next job is to dump the date to an SD card and maybe then onto the web.

When doing a Tallymode run recently using Mk2i_rev5a, the numbers didn't look right.  There was still an offset which was dependent on the size of the tallies.  I believe I've finally solved this long-running bug, the problem being in the routine, tallymode_updateData().  This code is now simpler and looks right, and the new version appears to pass all the tests I can throw at it.  With no current flowing at the CT, the resulting values that I'm seeing are firmly bunched around zero Watts, regardless of the size of each tally or where the zero point lies in the operating range.  This new version is attached as Mk2i_rev5b (or Mk2i_PV_Router_rev5b, to give it its full name).

Mk2i_rev5 had several changes from the rev4 version, probably too many.  There was the introduction of multiple loads, and  the capability of controlling one of these loads remotely, via an RF link.  I also altered the AF logic to a new scheme which lends itself to a multi-load setting and which doesn't require calibration.  Just before releasing this code, I added a flag so that the code would still run without the RFM12B module being present.  Although not actually required when this flag is inactive, remnants of the RF unit's code are still executed, and the Jeelib header file is still #included.  This is not an ideal situation if the RF unit is not actually being used.

Although rev5 does work both with and without the RF unit, it would be difficult now to separate the various features which have been combined together in this build.  For example, it's not currently possible to run the original 2-threshold AF scheme with multiple loads.  Having said which, that combination would not be without its difficulties.  With twin-thresholds, if one load fails to have the desired effect, there's very little time to switch a second load.  The new AF logic in rev5 overcomes this limitation by switching each load on or off sooner, thereby allowing more time for a subsequent load to be brought into play.

I also intend to fix the Tallymode code in Mk2i_rev4, and will release this as Mk2i_rev4b.  This will incorporate the rev5 -> rev5a change which was to prevent the output stage being active during the start-up period.  Mk2i_rev4b will have no reference to the RF module and will retain the original 2-level AF logic, but it won't support multiple loads.

With a bit of thought, it should be possible for constructors to mix and match the various components from these two baselines.  For a fast version of the code that doesn't use interrupts, Mk2a_PV_Router_rev3 is a good choice (but the Tallymode routine will still have a small error).  Or for a simple version that uses analogRead() and floating-point maths, Mk2_PV_Router_mini_3 is the one to go for.

There are links to all of these builds at http://openenergymonitor.org/emon/node/1757 (when I get around to updating it!)

I have been successfully running the PV router for the past couple of months using the mini_3 sketch and on average producing about 10 kW per day. I know need to take this a step further and move the connection to a remote heater with rd modules (rfm12b). My question is what hardware do I need. I am currently using the Arduino Uno and the complete kit from RichMC of this forum. I am guessing that I will need the rf unit at the base station and relocate the triac board into the remote station along with another Arduino Uno and another rf module (rfm12b). Maybe there is an easier and cheaper way of reaching my goal? Also, what sketch will I need to run this setup. Many thanks.

You need to equip the "controller" (which is the processor and the measurement front end feeding it) with a radio module, then you need to equip the "switch" (which is separate processor with the triac on its output) with another radio module. Plus another power supply - the switch only needs 5 V d.c. You might find it easier to use an emonTx instead of a Uno and RFM12B in the switch - just change the series resistor feeding the opto-isolator for a slightly lower value to account for the 3.3 V drive to it.

For sketches, the Mk2i_rev5 (with priority set to the remote load, though it would automatically use the remote load anyway if there wasn't a local one) and the RF_for Mk2_rx should do what you want.

The cheaper way would be to run a twisted pair of "telephone" wire between the controller and the switch. In this case the switch is just the opto-isolator, triac and heatsink. All you're doing is driving a LED - no radio modules, no second processor, no second power supply.

thewaver:  If you want to use a standard Mk2 build with RF capability, then it will have to be a variant of Mk2i_rev5.   The version that I released yesterday - Mk2i_PV_Router_rev5b.ino - would be fine.

At the base-station end, you would need to add an RFM12B module along with dropper resistors to convert the 5V signals from the Arduino into the 3.3V ones that the RF unit uses.  The diagram for this adapter circuit is on the first of the Networking Building Block pages; the completed assembly can just plug straight into the Uno's connector strip.  When testing your RF link, a pair of simple sketches are available; the link is on the same BB page just below the adapter circuit diagram, in "Software".

For the remote end, you'll need some kind of AT386-type processor and another RF unit.  The cheapest way to achieve this may well be with an emonTx unit that already contains an RFM12B.  Rather than buy the complete kit, you may be able to save a few pounds by just getting the bits that you actually need: PCB, processor & crystal, plus the RF unit and a handful of passive components.  To program this, you'll also need a programming adapter and M->F USB cable - and a certain amount of patience.  Another Arduino, with an identical RF adapter, may be an easier solution for you.

As noted at the top of the Mk2i_rev5 code, the associated sketch for the receiving end is:   RF_for_Mk2_rx.ino
 

PS.  I've just seen Robert's reply which seems to be giving much the same info, but more succinctly!

The Tallymode fix is now available in the Mk2i_rev4 code as Mk2i_PV_Router_rev4b, as attached.  The results now look much better than before.  When no current is flowing, there's no offset; the numbers are closely bunched around 0 Watts. 

I always felt that something wasn't quite right with Tallymode numbers but didn't get around to fixing it until yesterday.  Sorry for any inconvenience caused. 

(For completion, I've also upgraded the Mk2a line too.  This now displays the  power values in Watts, rather than in tally numbers, which is much easier to use.)

Thanks for your reply. I like the idea of having a second Arduino and a second rf unit for the remote end, this seems the easiest and simpler solution. What sketch would be used for the remote end ?, Also, would I not need a triac to drive the heater and a separate 12v supply to drive the remote Arduino. Lastly, it would take a lot of work to run a cable to the remote heater which is why I am having to go down the rf route.

thewaver: as posted earlier, the sketch for the remote end is  RF_for_Mk2_rx.ino

If you can't easily run a cable to the remote load, then you will indeed need a power supply for the remote processor which terminates your RF link.  You will also need a trigger + triac circuit at the remote end.

For those wishing to add RF , take a look at Jeenode.   I'm working on a pcb module to add the Voltage ref, CT , AC ref, ZCD triac driver and triac.  Just populate whichever end you need (TX or RX) or both if driving a local load hardwired.  It's a way away yet.

For those wanting to add RF to an existing 5v Arduino project, take a look at RF breakout board that includes the 5v to 3.3v conversion.

This is from the guy who wrote the RF12 library as used in Emon etc. which is included in JeeLib.h.  His board have smd layout to solder the RF12 pcb if required.

He has loads of other plug in modules.  All open source or you can buy the pcb's or kits.   I've currently got 10 jeenodes in development on 433mhz and 866mhz..   You can also buy jeelink with built in RF to send and receive from your PC.

You just need an FTDI adapter for connect usb to a jeenode.  Right angle or straight depending upon your 6 pin connector orientation.  You can pay more for the "Arduino usb serial light"  or you can buy a jeenode usb with the usb connector built in.

I had completed a completed MK2 stand alone PCB design (Atmega chip onboard and no use for an arduino board) when I came across jeelabs and started again from scratch..

Laurence

Hi   Pleased to report another MK2i rev 5b PV Router fully operational..well done Robin & thank you for assisting in the RF code problem you PM'd me. Although I am using twisted pair to the primary Immersion switch I intend to use RF for secondary. Just waiting for the RFM12B's to arrive. Anyone found a source for 1/2 wave 433mhz whip stub aerials at reasonable cost or alternative coil aerial that has been used within case.

I am really interested in the proposed useful addition that was mentioned by GTEC and Robin on the 11/5/12 for the override function. Did any code get done or is in the wings?
Robin, I know you said it should be easy using 2 digital pins but using the RF modules means these are occupied but I believe analogue pins can be used also. I think this would be useful for use at either outputs. Any assistance greatfully received as I'm not good at coding

To use your spare analog pins as digital drivers, the all-important thing you need to know is that the numbering for these pins follows straight after the digital ones.  So, analog 0 is "pin 14" and analog 5 is "pin 19".

The attached sketch blinks one digital pin and one analog one :)

PS. If driving an LED, don't forget the series resistor to limit the current!

To force the immersion to come on manually, the easiest approach is just to wire a mains switch into the Line (brown) conductor in parallel with the triac.  This is how my own system works as featured in several videos.  When either of them is on, the immersion heater will receive power.

Providing an over-ride function from within the code is a little more involved.  You first need to de-bounce the input as I've done for the pair of switches that are used in my Mk2i rev4 and rev5 code.  Once the new state of the switch has been reliably detected, it's then entirely straightforward to force the triac to stay on. 

In the rev_4 code, just replace the normal logic by   nextStateOfTriac = TRIAC_ON.

Hi,

How critical is mk2i for transformer ?

For emonTX/measuring power I understand the need for minimum phase shift etc but for mk2i its measuring bucket so at first thought transformer does not make so big difference ?

Maybe a din rail mount 8VAC EC approved transformer (or maybe 12VAC with diferent R1/R2 ratio) would be much more tidy install.

Robin has found that phase shift has very little influence on the action of any of the Mk2 controllers - probably because the load when the controller is operating is close to unity power factor anyway where a phase shift makes little difference. Obviously, if there is a very large phase shift, you might find that there is enough error to cause either a charge or export, if it is not corrected with phaseCal.

This may be helpful in case someone else builds mk2i using EmonTX

/*

// Original Pin settings

const byte outputModeSelectorPin = 4;   //  for normal or anti-flicker mode
const byte loadPrioritySelectorPin = 5; //  local or remote load to have priority
const byte underflow_LED = 6;           // non-essential, may have to be axed.      
const byte overflow_LED = 7;      
const byte surplusPV_LED = 8;  
const byte physicalLoad_0_pin = 9;      // for trigger (active low)
*/

// Pin settings for emonTx without switches etc...

// digital input and output pins
const byte LED_detectorpin = 6; // No meter input in use
const byte outputModeSelectorPin = 4;   //  for normal or anti-flicker mode
const byte loadPrioritySelectorPin = 5; //  local or remote load to have priority
const byte underflow_LED = 7;          
const byte overflow_LED = 8;           
const byte surplusPV_LED = 9;           // onboard led
const byte physicalLoad_0_pin = 3;      // Pulse input plug for trigger

There's a picture of the emonTx with all I/O labelled, under Modules > emonTx

Hi, I am ready to start this project and have ordered the arduino board and was going to order 2 x rfm12b but had a thought, can the rfm12b be set for transmit and recieve ?

Is there a time lag of any significance between excess detection and firing the triac with the rfm12b setup.

Is it  possible to have a hard wired device for excess soakage and when this is satisfied, it moves over to a secondary soakage device which is rfm12b controlled ?

Thxs Don....

Don, interesting questions.  When surplus power is being diverted, one can never know when the next on/off message will appear.  If a second transmitter is within range, there would always be the danger of a collision which could adversely affect the primary operation of the system, which is to divert surplus power reliably.

Is there any time lag? The simple answer is no.  There's already a 10mS delay between an on/off decision being taken and implemented.  The RF link delay is generally less than this.  It all depends on what else the receiver has to do.  If it's busy doing something else, then it may take a while to get around to processing the RF message.  But if it's just sitting there waiting for the next message to appear, as per the receiver sketch that I've posted, the end-to-end RF-link delay will only be a few mS.

The answer to your final question is "yes".  That's exactly how my rig at home was set up.  My primary load has always been the DHW immersion heater which is hard-wired.  Any secondary load has been RF controlled, as per my video of a storage heater.  Several other people have adopted this approach too.

Hi,

Thank you for your informative reply. I think that I didn't explain myself to well in the first question. For the base station, do I use a RFM12B to transmit the data and at the remote slave module, do I use another RFM12B to receive the transmitted data. I am assuming that the RFM12B can be set to either transmit data, or receive data. 

Also, it there any circuit diagrams of your Mk5 station with the transmitter and the slave module with the receiver. I can only seem to find bits of circuits, not complete diagrams.

Thxs Don...

Don,

The RFM12B module is "half-duplex" - it can both transmit and receive, but not at the same time. The GLCD does exactly this - receives data from the emonTx (energy) and the base (time) and transmits back the inside temperature.

Been running mk2i for a month now, flawless as we all know. Sometimes I do think that the mk2i would be even more purrrfect if diverted power could be calculated and value transmitted over using RFM12B (duty cycle % * dump load W)  just to know how much power has been diverted.

Petrik,

In general, if you are using an immersion water heater, that's not possible without measuring the current. You cannot know when the thermostat has overridden the controller, so it is impossible to calculate the diverted power.

I hate to disagree with you Robert but it is possible to use the overflow and underflow leds (or their equivalent in the software) to determine if the stat has opened and also when there is insufficient PV to dump any power at all.

Bob

Maybe its just possible to focus at divert duty cycle (like in martins scritp) to determine export and after that to check the condition for thermostat.

I agree with Bop that there is several ways of figuring out the thermostat state - but it all starts by modifying mk2i script to allow duty cycle % monitoring and report that using rmf12b if you guys feel its part ot this excerisise.

9fingers:

True - but only if the load exceeds the generation capacity. Otherwise, it can still overflow and still be dumping energy. There's no general failsafe method that will be applicable in all circumstances, short of actually measuring it.

Martin did it by feeding temperature into the controller, so his thermostat never opened - the diversion didn't happen when his water was up to temperature, so that's why his sketch could calculate diverted energy/power.

So you can always know the energy available to be diverted, but that is not guaranteed to match the actual energy diverted.

At least in my case it would be fairly easy to detect that when diverter is on the energy bucket is constantly emptied in 100ms (powercal). If diverter is not on then energy bucket is always filled to max. There may be rare co-incidental moments when bucket is emptied because of bormal load being increased but not significant in the quantity of bucket changing from full to empty.

In practise a good enough method to determine load state (knowing that is really on all the time) is just to check that the frequency the bucket is emptied is constant . Anyway I am less worried about load state as its on most of the time anyway.

Of course implementing anything like this is a matter of preference and need. Also I could do it but dont want to start yet another fork to be maintained, therefore presenting this merely an idea to be considered.

I stand corrected Robert. My dump load is greater than my PV capacity  so has not been a problem for me.

I simply count the number of cycles that the SSR is fired compared to the total number and average it to give near real time readout of power and a daily accumulator of power dumped. I don't have  a RTC in my system and simply used the end of a long period of no activity to indicate the start of a new day. Not perfect and could be fooled but seems to work quite well.

Bob

When reading the Robins code been wondering about the settling time before mk2i starts to operate. Its not really the filters that needs so long settling time but rather AD conversion to stabilize - or ?

Petrik - very little of the Mk2 code needs time to settle, but it seemed a good idea to disable the output stage for a few seconds after startup. 

Don - sorry, there's no integrated diagram of how everything in Mk2i_rev5 fits together.  With all of the main components already available, people need to piece together the bits that they want themselves.  If you encounter any problems, there should be plenty of help available.  I'm always happy to reply to PMs if constructors of Mk2 systems find themselves stuck.

As for measuring the amount of power that's been diverted, this would be entirely feasible by including an extra CT into the system.  It would just clip around one of the leads to the triac so would be entirely contained in the Mk2 unit. 

With a second CT in the loop, the sampling process would be slowed down by around 50%.  The basic FP version, e.g. Mk2_PV_Router_mini_3, would then run at only around 30 loops per mains cycle.  If using one of the later versions, e.g. Mk2i_rev5 which samples much faster, the sampling rate would still be at a good level, at least 50 per second.

If using an emonTx, the physical board space for the extra components is already there.  If not, then the extra few components would need to be mounted on an offcut of stripboard or equivalent.  The code upgrade should not be too demanding.  There would just need to be a second energy accumulator for the power that has passed through the triac. 

If the dump load is at the far end of an RF link, then the processor in the remote unit is probably very lightly loaded.  Why not include a standard measurement facility at the remote end?  It's probably easier to start again with the Mk2 version of your choice, and then add in the handful of RFM12B components that are required for the RF receive functions. 

The diverted energy can then be determined along the lines of:

#define JOULES_PER_WATT_HOUR 3600

float diverted energy; // as accumulated each mains cycle using the CT and the voltage sensor

unsigned int divertedEnergyInWattHours = divertedEnergy / JOULES_PER_WATT_HOUR;

With a second CT in the loop, the sampling process would be slowed down by around 50%.

Sorry, what I meant to say is that it would run at around two-thirds of the rate of the normal version.  That's because there would be three analogRead() calls per loop rather than two.

Maybe I am missing something so asking for curiosity: Why would a second CT be preferred method ?

It should more simplier to calculate (triac on loop count) / (total loops count) * loadW. This method should not even affect performance.

You only need a second CT to measure load if the load is smaller than the max power to be dumped for all dump loads

While bucket does not overflow (triac on loop count/total loop count) * Load power of particular dump load

Bob

Counting the number of cycles for which the load is 'on' is fine as an estimate of the consumed energy, but it's only an estimate. 

What happens if the mains voltage changes by 1%? - the power would change by 2%.  What happens when the thermostat trips?  - your estimated value of consumption would continue to increase but the actual amount of diverted energy would not.  What happens if the rating of the load changes, or is less than the max amount of surplus PV etc. etc.?

By adding a second CT, you can measure the diverted power just as thoroughly as the net flow at the supply point is being measured.  For an accurate value of the diverted energy, the system would need to be properly calibrated. 

Hmm, voltage drop can be counted in as its purely resistive load fairly accurately Vrms/Un * P. Tripping thermostat can be detected from SSR/Triac duty cycle going to 100% constantly (assuming dump load P is higher than maximum excess P) within a small Wh threshold limit.

But yes - this is a matter of application and acceptable tolerance which can be only judged by brilliant brains of the chief designer.

Hi, has anyone used the cheaper Chinese Triacs in place of the BTA41. I need to get 4 of them.  With a difference of about £2.00 each, thats a nice saving by going for the Chinese alternatives. Just have a reservation of how safe they are ??

has anyone used the cheaper Chinese Triacs in place of the BTA41.

No, but I have successfully used a 25 A version, when the 40 A one wasn't available.  This is slightly cheaper and appears to work fine for Mk2 Router purposes at 13 Amps.

The problem may come in hot weather when the router is going flat out. The BTA41 can pass 13 Amps at a case temp of 110 degC, which sounds mighty impressive to me.  Whether cheaper alternatives could survive such treatment is another question.

The point about using the higher current device comes down to its I²t rating, which directly relates to its ability to blow the fuse/trip the breaker protecting it. The 40 A device stands a reasonable chance of doing that, the 25 A version stands little chance - more likely it would protect the breaker or the fuse.

Either should be satisfactory in normal service.

Yes for a month Fostec 25A SSR with mk2i and 1kw dump load, according to specs 25A version can take 5-7A without cooling (if my memory serves me right). In normal sunny days it barely reaches 40C with around 800w dumping, this SSR has a din rail mount though. Recall vaguely someone having bought a 25A copy which did not have triac screwed (;-?) to the back plate where as real ones have a screw holding the triac thermally connected to the back plate. This would obviously affect max current.

Do you Robert mean that 25A version should not be used with 10A fuse or do you mean that t is not recommended to have 25A fuse for SSR with the 25A fuse rating ?

I think I spelled it out here. It's a matter of which one heats up and melts first. The BTA41 should survive if, at the current you have, its curve (the red line) is above and to the right of the fuse /MCB's. Otherwise in the shaded area it might not, and to left and below it won't.

I am new to forum but have been following the evolution of mk2 from jan this year , can you suggest which sketch is suitable for a basic load and program alteration for my meter ace 1000 itron (packet of 1250j).

Hi Dean, to provide a basic diversion function for surplus plower, the original Mk2 sketch with floating-point maths would do the job fine.  Mk2_PV_Router_mini_3 is a trimmed-down version which does not have the bulk of the original.  Because it does not have an anti-flicker mode, this sketch will work fine with any type of supply meter.

If you require your system to have an AF mode, then Mk2i (rev_4 or greater) would be the most straightforward way to go.  Alternatively, it should not be difficult to add the AF mechanism into a simple base sketch such as Mk2_mini_3.  The energy bucket for that sketch is in Joules so it would be a simple matter to re-define its capacity to 1250 (as required for your meter) rather than 3600. 

Hi Robin thanks for the help ,hope to get the system going soon before summer ends. Keep up the good work, videos very helpful thanks again Dean.

Hi Dean, I also have an ace 1000 meter. Where did you find the reduced packet value? Has changing the sketch improved the performance? There seems to be two places to change the 3600.

Thanks Keith

Hi,

I did some testing on the ACE 1000 meters as I couldn't get the AF to work with the packet value at 3600. After this testing I found it to be 1250 for that particular meter.

If you change;

#define JOULES_PER_WATT_HOUR 3600 // 0.001 kWh = 3600 Joules

to

#define JOULES_PER_WATT_HOUR 1250 // 0.001 kWh = 3600 Joules

it should work ok in AF mode.

In the MK5i I think you also have to change, (I don't use this version).

energyAtLastOffTransition_long = 3600; // reset the 'opposite' mechanism

to

energyAtLastOffTransition_long = 1250; // reset the 'opposite' mechanism

Keith, I don't know for certain that the 'sweet-zone' of the Ace meter is 1250 Joules, but several people have mentioned this value so I'm happy to regard it as being correct.

Depending on what the modified code is required to do, it may be OK for the value of 3600 to remain, this being the number of Joules in a WattHour; it's only the size of the 'energy bucket' that should be changed to match the sweet-zone for the meter that is being used.  In well-structured code, this change should only need to be made in one place. 

I trust that my various published sketches meet this criterion.  If any of them don't, please let me know!

Hi Robin et al.

Is it better to sink current, or source current from the arduino board to drive the LEDs.

But firstly, It seems de rigueur for this forum that at some time one comes out of the closet (or airing cupboard in my case) and admits to having been a lurker, well here I am, a repentant lurker!

I found this forum after I’d built my own temporary diverter.  I used a step down transformer to make sure that the power required for the immersion heater could be contained within the envelope of power produced by my PV without recourse to any phase or burst control.  It has worked fine and served me well, I certainly wouldn’t recommend it and it has major disadvantages but I’ve used it whilst I embarked on a better solution and understanding of the problem.

I’ve really enjoyed being re-educated in what was my subject having studied Electronic and Electrical Engineering at university, I started work in the Mullard Research and Application labs I slowly lost the “hands on engineering” and moved into management. Hey ho – that’s life, and money!!!

My own system had four outputs, prioritised and cascaded down using small relays to drive zero cross SCR blocks, I had them in the bottom drawer so Heath Robinson eat your heart out :-).

When Robin’s MK2i – 5B, came out I thought I’d better make the most of the sun and optimise the solution, so I modified my ‘birds nest’ to accept an Arduino Board, downloaded the software and modified it for 4 physical loads, and fired up the “Quattro” again. Without hesitation the supply meter LED went RED, the primary load started heating and through the day, all loads were switched on at various times…brilliant, but the LEDs didn’t seem to reflect my understanding of their function. 

In the end I realised I’d connected the LEDs to 5V, and the current version of Robin’s code expects them to be connected to ground, I’m sure I’d seen an earlier version with a circuit the other way round, anyway it was easier to change the code (It’s only the glue which holds it together!!!), so 0=1, 1=0 in the LED code and bang the old Quattro was firing on all four cylinders and the lights were working, correctly.

It begs the question is it better to sink or source the current from an Arduino board?  On face value the chip can sink or source 40mA, I’m under driving the LEDs through 1K ohm, so comfortably within spec at circa 5 mA? 

Looking forward to any comments if you get past the detritus of the opening :-)

Perfect, thank you Robin, Robert , and all the other active members for a very interesting and enjoyable re-discovery of electronics and how to solve the problem of diverting energy efficiently and effectively, and now I’m starting to learn C++ which was starting to be used by the time I was leaving the bench environment.

Just starting a new project to store the suns energy in the house and at the same time bring a little sunshine to our north facing rooms with a Heliostat, now that’s surely counts as lateral thinking. 

Anybody done anything like this yet, or is it too far off the wall??

All the best and regards, Simon
 

I prefer to have the LEDs connected to V_CC (active low) with a 3.3 V supply and that's because the low output voltage is lower than the high output voltage is high. If that isn't very clear, the data sheet tells all (Electrical characteristics, section 28.2). Doing it that way round makes the dropper resistor a little larger, and less susceptible to component and supply tolerances. This can be important when you are driving, for example, the triac driver. With a 5 V supply,  it is the other way round (there is a greater voltage available to the load when the load is connected to GND and the output is active high) and it's usually not so critical anyway.

When I was rushing around to publish my first Mk2 package, Robert kindly worked out that an active-low drive for the output stage would be best, and that 180R would be a suitable value for the series resistor.  That was for when an MOC3041 opto-coupler is being driven from an Arduino.  If using an emonTx which runs at 3.3V rather than 5V, a smaller value of series resistor is appropriate - I use 120R. 

I've always driven LEDs in active-high mode, simply because it feels more logical.  If you're short of pins, an LED can be satisfactorily driven in parallel with the trigger (active-low), but it would need its own series resistor. 

With the RFM12B, what is the difference between antenna lengths. Which is the best length to install, 1/4, 1/2 or full. Obviously, I want the one that gives the best reception. Also, does both the transmit and recieve have to be the same lengths?

I am mounting my RFM12B on the same vero board as the master components (Mk2i_PV_Router_rev5b) and the only space left is next the the 9v ref transformer, will this interfere with the transmission signal?

Lastly, on the slave box, is there anyway I can connect a LED to the gate connection of the Triac so that when testing I can see that it is sending the signal to the triac. This will save me having to connect it to the mains electric for proving that everything is functioning OK up to the triac connection.

TIA Don....

When I started playing around with the RFM12B, I seemed to be getting poor reception with just the standard 82mm lengths of wire that were supplied as aerials for my 868 MHz modules.  When I doubled the length of each wire, the performance seemed to improve.

Having tidied up my act somewhat, I no longer seem to be finding any transmission difficulties.  I'm now using 1/4 Wave aerials from chinaRF without any problems.  I can't find the exact item now but they look something like this - I bought 10 x 868 MHz ones for around £25.   For  distances of just a few meters, there's no need to actually fit the aerials; there appears to be sufficient radiation/reception just from the RFM12B modules and the short lengths of coax to my bulkhead connectors.

To see when the triac is on, you could use a neon.  My own Mk2 Router no longer has any LED's.  The neon indicator within the adjacent over-ride switch does the same job regardless of how power is being applied (diverted power via the triac, or constant via the metallic path).

How did you manage to fix the aerials from ChineRF to the rfm12b boards. Every picture or video I have seen shows them working with a piece of wire soldered directly to the RFM12B module.

The neon is good method to confirm the triac is working but this still means having to connect majns to the board, which I  am trying to avoid. My preferred solution is still the LED. Is this possible and how could I do it, it there a circuit drawing depicting this?

TIA...Don

Don, your triac already has mains connected to it.  All you need to do is connect the neon between the switched-live pin of the triac (A1 on my Mk2 schematic diagram) and Neutral.  The benefit of this system is that it will always indicate when power is available to the load.

A LED can be driven from any of the i/o pins on the processor, either active-high or active-low.  To save using an extra pin, it can also be driven direct from the pin that controls the trigger.  I've described how to do this here.  A LED that's controlled by the processor will not come on if there is a high-current bypass switch as an over-ride facility.  But it would come on if the over-ride ( or "boost") mechanism is controlled by the processor.  

To connect my aerial to the side of the box I've used a compatible bulkhead connector, also from chinaRF.  To fix the bulkhead connector in place, I used some 2.5mm screws & locknuts as per photo.   An easier approach, but possibly less rigid, would be to use the type of bulkhead connector that is retained by a screw-on ring.  This topic was aired on the forum a couple of months ago with all the relevant details/links.

Soldering the coax's braid to the connector's mounting flange, as I have done thus far, is not ideal.  It would probably be easier/better to solder the braid to a small eyelet and then capture this under the mounting screw.  A similar arrangement could no doubt be devised for the lock-ring type of bulkhead connector.  Providing some form of strain-relief at the RFM12B end of the coax is another challenge.  I'd be interested to see how others have gone about solving this one.

Robin, you're missing the point about the neon/LED. Don wants a low voltage device he can test safely with.

The short answer is no, you can't easily do anything with the high voltage side of the opto-isolator/trigger IC, but you can replace it on the low voltage side with an LED. That will show when it is being asked to fire (but it won't prove that the HV circuit is correct).

The only way I can think to test the HV side in relative safety is to feed it via a 1:1 isolating transformer. You'd need about 50 - 100 VA rating in order to use even a lamp as the test load, and you'd still have 240 V there, but it would be floating with respect to earth so there would be a much reduced risk of a shock from accidental contact with one wire (but NOT of course from two).

Robin, you're missing the point about the neon/LED. Don wants a low voltage device he can test safely with.

Maybe I am, but you can't test a live triac with an LED!  The trigger/triac at the remote end are being fed from an Atmel 368 processor in just the same way as if there was no RF link present.  Doing LV and HV tests at the remote end is therefore no different than when using an all-in-one design. 

The input (LV) side of the trigger is electrically no different than a standard LED; indeed, an extra LED + series resistor can be connected in parallel with it.   It's only the output side of the trigger device which is HV.

Lastly, on the slave box, is there anyway I can connect a LED to the gate connection of the Triac so that when testing I can see that it is sending the signal to the triac. 

Hope I've answered the above (I think you mean the trigger rather than the triac).  It's best to think of the "trigger + triac" as a combined item.  If you connect them up correctly, they should work as intended.  Beware - if you get the A1 and A2 wires crossed over between these two components, the triac will stay on permanently.  Not sure why, but it does!

what I am looking for is a LED connected in parallel with the circuit that fires the triac (although there will be no triac or Mains voltage present). So when I am testing the project, as soon the the LED lights up, I know that the circuit (RF master and slave) is working up to the triac gate connection.

I would be grateful if someone could detail the exact circuit for adding the LED (and resister?) to the triac circuit.

TIA.....Don

Don, I'm confused by what you mean when you write "triac circuit".  Apart from the handful of resistors and maybe a snubber capacitor, there are two main components in the output: the triac and the opto-isolated trigger.  Triacs will work down to low voltages, the resistors (and probably the line voltage sensing part of the trigger) are designed for mains (110 V upwards). And as the power for that isolated part of the circuit comes from the mains, it's going to be very hard to test sensibly without applying mains voltage.  What you can do, on the low voltage side as both Robin and I said, is: For testing, you can substitute an ordinary visible LED instead of the infra-red LED that forms the receiving end of the trigger i.c.

Looking at the data sheet, the emitter (LED) forward voltage is typically 1.25 V @ 30 mA, which is pretty much the same if not lower than a standard red LED, so it's unlikely that a standard LED in parallel with the opto-emitter will do anything. You could put your LED in series, but the additional voltage drop means that the series resistor must be reduced to provide enough current to guarantee firing the triac, and when you do all the sums it's not possible to find a resistor value that is guaranteed to work in all the worst-case conditions (i.e. at both maximum and minimum voltages etc for all the components and tolerances involved. So anything you do must be removed after initial testing to assure that the circuit will work correctly.

If, as Robin suggests, you put a visible-light LED and a separate dropper resistor in parallel with the opto-emitter and its dropper resistor, you need to run the new LED at fairly low current in order not to exceed the output rating of the processor I/O pin.

Hi Don, I've nothing to add to Robert's comprehensive reply.  If you're still struggling to see how to connect up your LED, maybe you could post a sketch of your circuit.  Then we would know what advice to give. 

In my original schematic diagram, the input side of the trigger sits between the 5V rail and digital pin 9.  If, also from pin 9, you were to connect an LED plus series resistor to the 5V rail, that LED should illuminate whenever the trigger is instructed to come on (regardless of whether HV is present at the triac).  The internal and external LEDs will be acting in parallel.  If, instead, you were to connect your extra LED to GND instead of the 5V rail, the two would act in anti-phase.  The visible LED would then be 'on' whenever the internal one is 'off', and vici-versa.

With a Uno, a suitable series resistor for the trigger is shown as 180R.  If using an emonTx at 3.3V, this value should be reduced to around 120R.

The lights, those lights, those blinking lights :-)

I seem to remember seeing a comment about the need for a health warning on the LEDs, it certainly does consume time, especially when you're on the cusp of balancing the PV and demand, as is the case at this moment.

.................... wait, wait, bear with,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, bear with,,,,,,,,,,,,,,, wait, OK  I'm back.......

Anyway, just linking into the previous conversations, I have neons in the remote load switches, so I can see when they are firing and I'm away from the central unit.

I have LEDs on the control panel to see when the outputs of the UNO are active for each remote load ( I have four), this is in the hall and is where I can change priority, select anti-flicker etc, and where the Underrun, Overflow, and Surplus lights are visible, and I have one more........

I know, I'm a glutton for punishment, but I thought I'd share this with you.  I have a single transistor buffer, switching an LED, which is controlled by an LDR sitting over the LED on the supply meter.  I know you have done this before and passed it through the processor, but this is totally independent of the processor, and just mimics the state of the supply meter LED, showing it either flashing, off or constantly on.  For me, it is a constant proof that the control loop is behaving properly, easy to view, and in the end it is this LED, this blinking LED for which I pay.

So I like the idea of having a 'belt and braces' approach, and an independent path of proof, constantly visible, just in case I do something silly, my meter is outside, and it has helped my wife to see what's happening!!, she made ME turn some lights off := RESULT!!

I can tell you now the meter is in anti-creep mode, immersion hot, and second load already heating, I have had it where all four loads have been active but not today. :-(

Regards Simon

I like it.  As you mentioned, the Mk2 code is already able to monitor the meter's LED and analyse its activity.  Relaying the state of this LED to a remote one is straightforward enough via an unused i/o pin.  But if a transistor will do the same job, that sounds an excellent way to go. 

It would be a neat improvement if the state of the meter's LED could be incorporated into the dump-load control logic.  At present, the energy bucket always fills to a certain level before the load is turned on.   During this process, some energy may be lost to the grid; it all depends on the relationship between the two measurement systems.  If the Router's logic were to know exactly where the present energy state is (within the meter's own energy window during periods of consumption), that initial  loss of useable energy could be neatly avoided.

I agree that one might possibly use this approach to stop losing some energy to grid but I was more concerned initially not to pay extra, so I was also thinking of using the parallel path as some kind of watchdog for the processor, (it's what I'm doing visually)  it does feel as if some logic could be employed to identify that if an output is triggered and the meter LED is not on (after a settling time, which might lose energy to the grid!!), that we might have got out of sync, or worse, processors do go AWOL.

So even if some logic does get added into the code, or on a shield as a watchdog, or as a gate function to the active low outputs to stop them firing unless meter LED is on, I will probably still keep a parallel functionally separate path to see the logic appears to be on target.  In my safety critical applications in the past we often had more than one processor running different code, checking each other.

In terms of display, I'm also thinking of using a PWM output to drive a small meter, maybe showing how full the bucket is, or using it centre positioned to show a very visual direction of power flow, especially good for seeing how close to the line, that you are

I have to say again, thanks to this forum and to your original work, it's made significant improvements to my original concept which was very inefficient, but I have to say worked. Your MK2i 5b  does work very well, today I am just PV positive, weather very grey, and it is working well, lights, those blinking lights  :-)))

Simon

Tried to install the MK2i 5b sketch for the Uno and got the following errors, can anyone help and tell me where I am going wrong ?

Mk2i_PV_Router_rev5b.ino: In function 'void setup()':

Mk2i_PV_Router_rev5b:443: error: 'RF12_868MHZ' was not declared in this scope
Mk2i_PV_Router_rev5b:443: error: 'rf12_initialize' was not declared in this scope
Mk2i_PV_Router_rev5b:444: error: 'RF12_SLEEP' was not declared in this scope
Mk2i_PV_Router_rev5b:444: error: 'rf12_sleep' was not declared in this scope
Mk2i_PV_Router_rev5b:512: error: 'Timer1' was not declared in this scope
Mk2i_PV_Router_rev5b.ino: In function 'void send_rf_data()':
Mk2i_PV_Router_rev5b:1242: error: 'RF12_WAKEUP' was not declared in this scope
Mk2i_PV_Router_rev5b:1242: error: 'rf12_sleep' was not declared in this scope
Mk2i_PV_Router_rev5b:1245: error: 'rf12_canSend' was not declared in this scope
Mk2i_PV_Router_rev5b:1247: error: 'rf12_recvDone' was not declared in this scope
Mk2i_PV_Router_rev5b:1250: error: 'rf12_sendStart' was not declared in this scope
Mk2i_PV_Router_rev5b:1251: error: 'rf12_sendWait' was not declared in this scope
Mk2i_PV_Router_rev5b:1252: error: 'RF12_SLEEP' was not declared in this s

Yes, you don't have the library for the RFM12B (JeeLib). Follow the instructions at http://openenergymonitor.org/emon/buildingblocks/setting-up-the-arduino-environment  for setting up your libraries.

Hi Robin, clicked on your link and it says page cannot be found?

OK Don, which link is not working?

It was the automatic parser that got it wrong when creating the link from plain text.

it was the last link you entered in this forum, how to setup keeping with arduino uno. I managed to find this link but cannot locate the jeelibs zip file. Why is it not straight forward. ???

Don, it wasn't me who posted that link, but I'm glad that it's now working for you. 

I hope that someone else will be able to help you to get your Jeelib library files set up correctly.  That's not my area, I have to struggle as much as anyone else with such things!

Robin

We don't control what Jean-Claude does in JeeLib. If you can't see a zip file, you need to look harder. I can see it.  You still have a choice to download the files one by one or install GIT.

I could see a likely looking Jeelib .zip file when I checked earlier today.  I followed OEM links as far as https://github.com/jcw/jeelib and then clicked where it says: "You can download all the project source files in ZIP or TAR format: "  The file is called jcw-jeelib-17a45b2.zip 

Another way to install library files is to copy the complete directory structure from someone else.  I think that's the route I took, some months ago.  My Libraries directory which includes the Jeelib folder is attached.  No promises, but it may help.

Version:1.0 StartHTML:0000000105 EndHTML:0000002490 StartFragment:0000002325 EndFragment:0000002454

(Sorry the system is not letting me add this attachment, will keep trying ...)

Hi Robin,

I am now getting close to turning on my RF "router". I have built it to the drawings that I have manged to find on the forum but I have a query with the gnd connections on the RFM12B module. On your video, you show your drawing with the ground (pin 14) connected but on the emon building blocks section, the drawing there does not show pin 14 as being connected. It shows pin 3 as the only ground connection.

If pin 14 has to be connected to ground, which ground does it need to be connected to, is it the same as pin 3 or ??

Thanks Don....

Don, it doesn't matter which of the three GND pins on your Uno is used for an RF adapter.  Any of them will do.

As one of these GND pins is adjacent to pins D10 - D13 which are required by the RF module, it's convenient to use a DIL strip to make all five connections in one go.  That only leaves 2 flying leads for D2 and the 3.3V rail. 

I built another of these units a few days ago as shown here on another thread.  Because of the additional front-end board for that project, the 3.3V supply takes an indirect route to get to the RF adapter.  But in electrical terms, that lead just plugs into the relevant socket on the opposite side of the Uno.

Thanks for your reply. Does the gnd connection pin on the RFM12B module (pin 14, top right hand pin looking from the top) need to be connected to gnd ?

Thanks Don....

No.  If you look of the back of the RFM12B, you can see that pins 3 and 14 are both connected to its groundplane.

I have built the router as per Robin's design. I need to know what is the output of Digi pin 9 of the Arduino when running the mini_3 sketch. This is the pin that drives the opto-isolator which in turn drives the triac. I need to test my board as it is not working and am trying to break it down into small modules. I am hoping that I can connect a LED to digi pin 9 to monitor the output to see if I am getting anything out of digi pin 9. Thxs don...

All of my Mk2 Router sketches drive the output pin low when the trigger (and hence the triac) is to be activated.  If everything is working correctly, and you connect an LED plus series resistor in parallel with the trigger and its attendant resistor, then both of them should operate in parallel.  

If you only have the LED connected, but no trigger/triac, then there will be no feedback because the current is not changing direction.  Any surplus power will cause the LED to come on, and stay on.

If you can explain which part of your rig you wish to investigate next, then a simple check for this can probably be suggested. 

Robin: Would a simple test sketch to drive the triac at (say) 20% power (2 s on, 8 s off) be any use to Don?

Thanks for your reply but I am lost. In simple terms can I put a LED between dig 9 and ground with a resistor (180 ohms) between the LED negative and ground. So LED + to dig 9 and LED - to 180 ohm resistor which is connected to ground. So when I connect the ct and it detects surplus, the LED comes on and when there is no longer any surlpus, the LED goes off. (or off/on rather than on/off)

There is no MOC 3041, triac or any other components connected that are related to the Triac circuitry. I just want to monitor dig 9 to see if everything is working OK up to that point.

Please, answers in very simple terms. Thank you for your patience and time.

Don....

"Thanks for your reply but I am lost. In simple terms can I put a LED between dig 9 and ground with a resistor (180 ohms) between the LED negative and ground. So LED + to dig 9 and LED - to 180 ohm resistor which is connected to ground. So when I connect the ct and it detects surplus, the LED comes on"

OK let's stop there. This is a closed loop control system. Until you have the whole system in place it won't work. It depends on the c.t. sensing the energy flowing backwards and forwards, see-sawing between the grid, your PV and the immersion heater. With the immersion not being controlled, that won't happen. So you must simulate it by hand.

Wire up your LED as you suggest. It should come on straight away because Robin's circuit expects it to be wired from the supply to the output, not output to ground. Use a low-power load - say a 100 W lamp just connected to the mains as you would. That will consume 100 J/s, so it will completely fill the "Energy Bucket" - 3600 J - in 36 s.  [The low power gives us time to see what's going on.]

Put your c.t. on one of the lamp wires. If the LED goes off inside 36 s, you're generating and so far so good. Unclip the c.t. and turn it round on the cable. After about 30 seconds (depending on where your thresholds are set) the LED should come on. If that happens, it's all working.

If the LED doesn't go out after 36 seconds (or maybe a bit longer if the calibration is awry), turn the c.t. around anyway. If the LED goes out after another 36 seconds, the c.t. thought the first time you were drawing power from the grid and you were emptying the already-empty bucket. By turning the c.t. around, it then thinks you are filling the bucket.

Yes, I'll go along with all of that.  My sketch Mk2_PV_Routrer_mini_3.ino displays the amount of energy that is being seen at the CT3 (An 1) each second.  With a 100W bulb connected, you should see +100 (Watts) when the CT is connected one way around, and -100 W when it is reversed.  When the energy bucket reaches 1800 Joules, your LED should go on.  Then, when you reverse the CT, the energy level will drop and the LED should go off. 

If this is not happening, try running my RawSamplesTool_4ss_2 sketch.  This will show you what your sensors are seeing.  If the results don't look right, then you can post them here and someone will no doubt steer you in the right direction.

Hi, I have tried what you suggested with no conclusive answers. I think that maybe my circuit is not performing as it should. Can I clarify that the 9 volt transfer is working as I thinks it should:

On the primary side (viewed from the top), there are 4 conections, only 2 are labelled on the top, the outside connections labelled 0v (left) and 230v (right). I have connected the mains to these 2 connections and not done anything with the 2 centre connections.

The secondary side has 4 connections labelled 0 - 9v   0 - 9v from left to right. I have just used furthest right pair and ignored the left had pair. My problem is that my meter only reads 1.11v (on the AC setting) on each of the pairs, should this not be reading 9 volts AC?. My meter is an old meter and the AC setting says 200/1000AC, so maybe my meter does not read anything below 200v AC accurately!!

I am using a blue YHDC CT: 100A:50mA,  SCT013. Do you know if this contains a burden resistor, or should I add one. Currently, I have no burden resistor installed on my board.

I ran the program that Robin suggested in his last comments and attached the results to this post. Lasty, thank you for your time and help

Don...

If you seriously want to construct projects like this, you need to get a reliable multimeter. You don't have to spend much. For less than the price of an emonTx, you can get a reasonable one like this: http://spiratronics.com/professional-s8-multimeter-en.html  (I don't own one, it's not super-accurate but it looks very good value for the money and will be an invaluable aid.)

The transformer primary: It's possible that there are two windings of 115 V each. If that's so, you need to link the two centre pins to connect the two windings in series. If you can check the resistance between the various pins, that will give you a clue. Is it an open-type transformer, can you see the windings coming to the connections? If you can see a connection to each of the centre pins, that's another indication that there are two primary coils and they need to be connected in series. If you put your meter across the two centre pins and read about 240 V, that's yet another indication of a split primary winding and you need to link those two pins.

The secondary side: It's OK to use just one winding, no problem there.

We know the 100 A SCT-013-000 does NOT contain a burden resistor, and you'll be overloading it without one.

The recordings are certainly not right. You need to sort out your 9 V and the burden, then try again.

Thanks for posting those results, Don.  It's always easier to diagnose problems with something you recognise.

With only 150W flowing through your CT, I would expect to see a very small signal on the 'c' trace.  A large waveform should only appear on that display when several kW is flowing.  This suggests to me that you've not got a burden in your circuit.  I would try adding a 150R burden.  If you leave the leads of the resistor nice and long, it will be easier to change it later for a different one.

At the start of each run, the count should read 4 3 2 1  not 4 4 4 4 3 3 3 3 2 2 2 2 etc.  This tells me that your voltage sensor is not behaving properly.  A related symptom is that you're not collecting 3 waveforms' worth of data as the results file claims to be doing. The logic expects the voltage waveform to be sinusoidal, which yours unfortunately isn't. 

It sounds as if you're generating your AC voltage using a transformer.  With everything disconnected, you should be able to work out which pins are which using a resistance meter.  With a 3VA dual 9V transformer, I can measure the resistance of the primary coil to be 800 Ohms, and each of the secondaries is approx. 5 Ohms.

If you were to run my MinMaxAndRangeChecker sketch, you should see a constant value of around 500 for each analog input that has a sensor connected to it (probably A2 for the voltage sensor and A1 for the current sensor) and just ingore the other columns.  That's when no AC is present.  Then, when you switch on the AC voltage, you should see the "range" column for the voltage sensor's input increasing from around zero to several hundred.  The current sensor should remain fairly close to 500 until you pass a large current through the CT.

By running these basic tests, and posting the results, I feel sure that your system will soon spring into life ...

many thanks for your replies, I will check these out today. Just a quick question Robin, you mention the dual 3va transformer, which I have and bought from Spiratronics. Did you have to solder the 2 centre pins together on the primary side as Robert Wall hinted at ?.

thanks Don...

The transformer that I tested yesterday was not from Spiratronics, it was from JPR Electrical.

Here's one that came from Spiratronix.  On this model, there are only two pins on the primary side rather that four.

If you're using one of their PCB mounting transformers, you should be able to identify the correct connections on the primary side by looking at the PCB layout that Rich has kindly provided on his Mk2 Route parts For Sale thread.

Hope this helps.

I am now getting 11.1 volts AC out of the transformer, so progress there. I have conneted the burden resistor (150ohms) and run the test RawSamplesTool_4ss_2 sketch. The results are not promising, I am now getting more 4,3,2 and 1's. I have attached the readings in the same format as before. Thanks Don....

That voltage wave is still nowhere near right. There are several options for the input circuitry - which circuit diagram are you following (I've looked back up this thread and I can't spot where you say anything about it)? Can you provide a link, failing that a scanned drawing?  I think there is something fundamentally wrong with your hardware and you need to look hard at the input circuitry of the voltage input (and quite possibly the current input as well) and carefully check it.

With no inputs (neither voltage nor current), the inputs should sit very close to 2.5 V and Robin's test sketch should draw a line of 'c's (but quite possibly only one or two!) right down the middle. This is what I got:

No of cycles recorded = 3
cycleCount 2404,  samplesRecorded 17
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
|                                      c.                                       |
minVoltage 505,  maxVoltage 506,  minCurrent 507,  maxCurrent 508

That (505/506 & 507/508) is close enough to 512, which is where it should sit.

(Robin's sketch won't work properly without a voltage input, but it still gives useful information about where the input is sitting.)

Firstly, thank you for your time in helping me trying ti get this to work. The circuit I am using is on vero board and the circuit is taken from this http://openenergymonitor.org/emon/sites/default/files/cct.jpg. As I explained previously, I am not employing the triac part of the circuit, I just have Digi 9 connected to a LED and the LED is connected through a series resistor to the negative on the Arduino board.

I have tried what you said earlier with monitoring the LED going out and then reversing the CT so it should come back on again, but no luck. I can get the LED to go off whichever way round the CT is, but cannot get it to come back on again, unless I reset the Arduino. BTW, I am running the mini_3 sketch for this test. The readings from this sketch are CT one way, about 55 to 70 and with the CT reversed, about 90 to 110.

I am wondering if having the USB serial cable and the 9volt supply connected at the same time to the Arduino board is causing mis-readings. All tests and readings mentioned here have been completed with only the USB serial cable connected, NO 9 volt supply as well.

I have a spare CT which measures 40 ohms from tip to sheild and was informed that this did not need a burden resistor and have tried this and attached the results which are taken when using Robins test sketch.

Don...

Don, while your input circuits are not behaving as expected, there's no point with moving on to other parts of your setup.   I have never found any problem with having an external DC supply present as well as the USB.  For test purposes, USB power on its own should be fine.

I don't have any PCB transformers from Spirotronics (VTX), but I've just bought a similar one from JPR.  This has four pins on the 240V side, only the outer two of which are connected.  There's a very fine wrapped around each of these pins, but not around the inner two. 

To check the voltage waveform, I connected one of its 6v AC outputs to an emonTx.  Although I've not used the normal socket, the signal plugs into the board in the normal place (analog input No 2).  To make the display more interesting, I fitted a CT to CT1 (A3) and clipped it around the Neutral feed of an extension cable which supplies power to a 2 kW room heater.

The sketch I used was RawSamplesTool_4ss_2.ino, exactly as posted, except that I changed the value of noOfCyclesToBeRecorded from 3 to 1.  The results file is attached.  I did two runs, the first with the load off and the second with it on.  These waveforms all look fine to me.

When you can get waveforms like this, then everything else will probably spring into life too :)

I second what Robin says about getting the input waveforms right. There's no point in trying to run before you can walk. Did you try with no mains voltage to the transformer on the voltage input and no c.t?   You see, my fear is the op.amp is unstable and is generating a high frequency wave that is adding to the mains wave, and it's that which is putting the 'v's all over the place. Have you measured the voltage at the op-amp output, and is it 2.5 V? Is the op-amp getting warm? Are you absolutely sure that you have copied the circuit onto veroboard exactly? Even if it all looks OK to you, can you do a clear sharp photo of both sides of the board for us to check?

Don, if your op-amp is in a socket, you could very easily convert your reference circuit to the standard (passive) arrangement.  Having removed the op-amp chip, you would just need to connect pin 3 (+ve i/p)  to pin 1 ( the o/p), and add a suitable capacitor (at least 10 uF) between this point and ground (pin 4 of the socket).  You would then have a 1-channel version of the standard reference circuit that's found on an emonTx.

With only one reference circuit, there will be a small amount of crosstalk (leakage) between your voltage and current sensors, but it should easily be possible to see what's going on.  If you start seeing sensible waveforms, that's great; there must have been some kind of problem with your amplifier.  If good waveforms do not appear, then it will be much easier to diagnose what's going wrong without the op-amp being in the circuit.

If the amp is not in a socket, and you want to cause minimal disturbance to your existing wiring, maybe you could build a new (passive) reference circuit as above somewhere else.  You can then connect this into your existing circuit in place of the existing reference from the op amp.   A pair of 10 K resistors will be fine for this reference circuit, there's no need to use 470 K.  They just need to be equal.

When some kind of isolation is needed on a strip-board circuit, it's often possible to simply break one track which can then be soldered across later.

Hi Thanks Robin for your reply. I live in Spain and getting electronic components is near impossible, I would have to order from the UK and this takes time. I have a spare op amp and will replace it to see if it is the op amp that is faulty. Did you check my readings3.txt sketch readings. I though that the last 3 were pretty good and looked quite true, these are the readings that had my 9 volt DC supply to Arduino board disconnected and just had the USB serial cable in place and used the other CT with no burden resistor.

I have checked and rechecked the vero board layout and everything is in place correctly, although I did find that i had the CT socket wired wrong until readings3 txt. I did not have the tip connected but the middle connected, which of course meant that the CT had only 1 connection which is why the readings could have been all over the place. I have a working version of your router on my own solar setup and I checked the resistance of the CT and this was 40 ohms, which is the same as that one that I am using now (for readings3.txt). Perhaps I should build the triac circuit and test with this is place?

Thanks Don....

(sorry, Don, I'd not checked all of your file when I first posted this reply ...)

Yes, the lower runs in Results3.txt do indeed look much better:

Run 1 starting at character 1 - not good, nothing useful there

Run 2 starting at character 202 - not good either

Run 3 starting at character 352 - this one looks a bit better, but is still not right.  It should have recorded 3 cycles

Run 4 starting at character 807 - Hooray, both waveforms are looking fine!  This is without your external supply

Run 5 starting at character 1545 - Yes, both waveforms are looking fine again.  

Run 6 starting at character 2283 - The current waveform should be a straight line, and it clearly isn't.  This tells me that your biassing circuit is somehow relying on your CT, which shouldn't happen. 

So there seem to be two problems:

1. Your external supply is upsetting the Arduino (which is fine when just the USB supply is in use).  RichMc has mentioned this kind of problem, but I've never seen it myself.

2.  Your current sensor does not work when the CT is removed.  Are you sure that there really is a burden resistor on your board?

I'll be offline for the next couple of days.  Hope you continue to make good progress.

About Robin's point (1) - Two possibilities spring to mind: either the 9 V supply is not man enough for the job and the Arduino is pulling the voltage down below 9 V, or it is possible that it is misbehaving, like these USB power supplies tested two years ago by Trystan: Not all USB power adapters are created equal.

It seems that all my problems have steamed form the 9 volt power supplies that I bought from China, they are just not good enough. Can I run the Arduino from good quality 5 volt power supplies which I have enough of ??

Someone with detailed Arduino knowledge will no doubt correct me, but as far as I know at least some of the Arduinos have an on-board 5 V regulator, so that an unregulated supply can be used. If that is the case with yours, and you are not using the higher voltage for anything, it should be relatively simple to remove the regulator and feed in your regulated 5 V at the appropriate place. If you've got a circuit diagram of your particular board, you should be able to tell from that what needs doing.

I have now bought 2 new 9 volt power supplies that actually work. For proof of working, my first test was to get the main box working as a standalone router (no wireless) running the Mk2_PV_Router_mini_3 sketech. My test setup is a 60 watt light bulb with the CT around one of the cores and a 40 watt light bulb connect to the output stage (Triac). When I turn the 60 watt lightbulb on, after about 20 seconds, the 40 watt light bulb comes on. I then reverse the CT and after about another 20 seconds (very roughly), the 40 watt light bulb goes out. I can keep doing this and the 40 watt light keeps coming on and off with evert CT reverse. Now, I think that this is working OK (I hope).

Now my next stage was to introduce the wireless circuitry and excactly the same is happening. I have the remote station with the 40 watt lightbulb connected and the primary station with the CT around the 60 watt lightbulb lead. If I reverse the CT, the light goes off and reverse it back, and the light comes back on.

I am doing this for a friend as I already have a non wireless router working on my own solar setup. My concern is that on my own setup, the more excess electric I produce which is used for my soak ( a heater) causes the LED (pin 13) to flicker. The more excess that I produce and use, the quicker the LED flickers. If I am producing no excess electric, the LED stays off. On my friends wireless remote station, the on LED (PIN 13, same as Arduino Uno on board red LED), does not come on no matter whether the 40 watt light bulb comes on or off (due to the CT being reversed).

Am I doing everything correct and is this working as it should be before I connect it up to my friends solar system.

TIA Don....

OK, from the first two paragraphs everything seems to be working properly - excellent. [Note for next time: cheap power supplies can turn out to be very expensive in terms of everyone's time and effort!]  As for the last paragraph, have you checked the remote sketch to see if Pin 13 is actually being driven by the logic? Does the LED work if you write a simple 2-3 line "flasher" sketch to test it? If you're using Robin's RF_for_Mk2_rx.ino, then Pin 13 is not the pin to use - see the comments and the pin allocation near the top of the sketch.

My test setup is a 60 watt light bulb with the CT around one of the cores and a 40 watt light bulb connect to the output stage (Triac). When I turn the 60 watt lightbulb on, after about 20 seconds, the 40 watt light bulb comes on.

After 20 seconds, your 60W bulb will have consumed 1200 Joules.  With all published versions of my Mk2 Router, the level in the energy bucket should reach 1800 Joules before the output stage can be activated.  This suggests to me that your calibration is around 33% low.  Mini_3 displays how much power is flowing through the CT.  In your case, it's probably showing around 90 Watts for your 60W test bulb.  Easily remedied by changing phaseCal.

Unless you arrange for some feedback to occur, you will not be able to see the system working so as to balance consumption with (simulated) generation.  To do this, you need to feed these two circuits through your CT in opposite directions.  You will also need to have a load which is greater that your source. otherwise the load once activated will remain on constantly.

A suitable test rig is shown near the end of Section 8 in the online article:

Hope this helps.

Robin: "Easily remedied by changing phaseCal." I don't think you mean that!  POWERCAL surely?

Have you tried anti-flicker mode if your LED is flickering very fast?

Or maybe that version of the sketch doesn't have the anti-flicker mode.

Robin: "Easily remedied by changing phaseCal." I don't think you mean that!  POWERCAL surely?

Yup, indeed I do :)

Have you tried anti-flicker mode if your LED is flickering very fast? Or maybe that version of the sketch doesn't have the anti-flicker mode.

The Anti-flicker option is only present in the Mk2a and Mk2i lines.  When running in normal mode, the LED does flick pretty fast, but the rate of flicker is not a particularly good measure of the power that's being diverted.  The easiest way to estimate the amount of diverted power is to count the number of cycles for which the triac has been 'on'. 

There are 50 x 60 x 60 = 180,000 mains cycles per hour.  So every 60,000 'on' cycles with a 3 kW load represents 1 kWh of diverted energy.

in my own set up, which is a router running the mini_3 sketch, I find the LED which is the Arduino pin 13 very useful for a visual indication of when my panels are producing excess electric. When it is not flickering, I then know that I am not producing any excess.

with my friends wireless router(as detailed above in this forum) that I am building, is there a similar pin on the arduino that I can connect an LED to, which acts the same as the mini_3 sketch. I would like to have this LED for both the base and remote station's. These are both running the latest sketches by Robin. (mk2i rev 5b and rf for mk2 rd) ??

Don, in my mini_3 sketch, the on-board LED is simply used to show the state of the triac:

          if (energyInBucket > (capacityOfEnergyBucket / 2))       
          {
            nextStateOfTriac = ON;  // the external trigger device is active low
            digitalWrite(outputPinForLed, 1);  // active high
          }
          else
          {
            nextStateOfTriac = OFF;
            digitalWrite(outputPinForLed, 0); 
          }
                 
          // then set the Arduino's output pin accordingly,
          digitalWrite(outputPinForTrigger, nextStateOfTriac);  
 

Because this build has no anti-flicker mechanism, the energy bucket's level is always close to the half-way point when surplus power is availble.  Every time that another 60 Joules appears, the triac in turned on for at least one cycle, and a "flick" is seen at the on-board LED.

My Mk2i sketches can run in this way (i.e. "normal" mode), but they can also run in an anti-flicker mode.  In AF mode, the interval between successive firings of the triac is much longer.  The on board LED will correctly not show "flicking" if the triac is being constrained not to flick!

Whilst in AF mode, it can be helpful to know whether any surplus power is available.   That's what the "surplus power" LED in Mk2i_rev5 is for:

const byte outputModeSelectorPin = 4;   //  for normal or anti-flicker mode
const byte loadPrioritySelectorPin = 5; //  local or remote load to have priority
const byte underflow_LED = 6;           // non-essential, may have to be axed.      
const byte overflow_LED = 7;      
const byte surplusPV_LED = 8;  
const byte physicalLoad_0_pin = 9;      // for trigger (active low)
...

        if (realEnergy_long > 0) {             // Update the LED which shows whether there is
          digitalWrite(surplusPV_LED, 1); }    // any surplus power.  This is particularly useful
        else {                                 // in anti-flicker mode when 'on' periods
          digitalWrite(surplusPV_LED, 0); }    // of the triac can be quite infrequent
 

For a per-mains-cycle indication of surplus power, just connect your LED (with a series resistor) between digital pin 8 and ground.

The most recent version of my Mk2i code, rev5b, will be used as the basis for various sketches to accompany my new hardware.  While refining this code, I've found that it has not been well constructed for operating at any mains frequency other than 50 Hz. 

Although my original Mk2 sketch had a cyclesPerSecond variable which was properly used, the hard-coded value "50" has crept into the interrupt-based version of this code in a number of places.  Although this oversight is unlikely to affect the basic operation of the router, it did need to be sorted out.

By way of apology to anyone who may have been affected by this, here is an updated version (rev5c) in which there is a  #define CYCLES_PER_SECOND 50  statement which does "just what it says on the tin".  To run this code run in the USA where the mains frequency is 60 Hz, this value simply needs to be changed to "60", that's all. 

Mk2 PV Router code has always been calibrated in the same way, by means of the single variable, powerCal.  This value is used to calibrate the hardware when measuring real power, which does not depend on frequency.  The Mk2i code includes a calibration mode in which power is measured and displayed.  If you were to run the rev5c code in Tallymode, and record the power drawn by a 40W light bulb, the result would be 40W regardless of the CYCLES_PER_SECOND setting.

So why does my PV Router code need to know the frequency of the mains?  The answer is that that it works by measuring the amount of energy (not power) that is flowing in either direction, and all of its timing comes from counting mains cycles.  If it were instead to repeatedly consult millis(), then a knowledge of the mains frequency would not be required by the code.

The measurement side of a Mk2 Router monitors the flow of energy at the supply point just as does the electricity meter.  Every known type of meter has a 'sweet-zone' within which energy can flow to and fro without charge or loss to the user.  The Mk2 Router can only do its job properly if it is measuring energy on the same scale as the meter does.   Hence it needs to know at what frequency the mains is running.

On a related theme, some meters in the UK (and no doubt elsewhere) have a sweet-zone that is less than 1 WattHour (i.e. 3600 Joules).  Thus far, there has not been a tidy way to enter this value into my Mk2 Router code, but now there is.  In the rev5c version, this value can be entered at the line:

#define SWEETZONE_IN_JOULES 3600    ...  and the size of the energy bucket will be set to match this value. 

A few general improvements to the code have also been included in the rev5c version, as attached.  As always, if you find any problems with this code, do please let me know.

Hi Robin,

I'm a total newbie, but with past computing experience (which I guess is a dangerous combination).  I've been trying to do some homework on your PV Router to convince myself that I can make it a core element of an energy strategy for a new build rural home. I'm hoping to install a 9.75 kWp PV array on a nearby barn roof (I'm guessing a maximum output of around 7.5kW) and I want to divert much of the output as possible to a thermal store to reduce the need to fire up a backup log fired boiler.  Yesterday's homework suggests a thermal store with two 3kW immersions at the bottom, and one 3kW immersion near the top (first priority for quick warmup).  I'm thinking I'd need the multiple loads to avoid flicker. This in turn lead me to Mk2i_PV_Router_rev5c.ino_.zip  which I've been reading through.

I'm trying to spot where my second and third immersion would actually be powered (digitalWrite) to no avail.  Am I missing something (likely given my struggling understanding) or should I expect to convert physicalLoad_0_pin into a 3 element array (for my intended three immersions) and reference the pins in a loop?

Apologies if this is typical newbie stuff.

Robert

It's fairly simple. You have to add physical load outputs for your extra load. So there are about 4 things you have to modify.

In Pinout assignments the original has only 1

const byte physicalLoad_0_pin = 9;      // for trigger (active low)

add some more

const byte physicalLoad_1_pin = x;
const byte physicalLoad_2_pin = y;

You have to map these to the Arduino pins that you want to use

in void setup() add the 2 extra pins

pinMode(physicalLoad_1_pin, OUTPUT);
pinMode(physicalLoad_2_pin, OUTPUT);

below that (under the loop) add the lines to make the new outputs low at startup

digitalWrite(physicalLoad_1_pin, physicalLoadState[0]);
digitalWrite(physicalLoad_2_pin, physicalLoadState[0]);

then about line 980 add them to this section

// update all other physical loads
digitalWrite(physicalLoad_0_pin, physicalLoadState[0]);
digitalWrite(physicalLoad_1_pin, physicalLoadState[1]);
digitalWrite(physicalLoad_2_pin, physicalLoadState[2]);

I've used this scheme to drive 2 physical outputs and it works fine. This is a mod to drive 3, but I haven't got round to testing it yet.

Hi Robert, your multi-load arrangement sounds entirely reasonable to me.

The Mk2i rev5c sketch can control as many physical loads as you can find pins on the processor for.  You wil just need to re-allocate a few pins that you can manage without, such as for LEDs.  My rig at home doesn't use any LEDs, nor will my new hardware; I just have a neon to show when the load is on.  Unlike an LED, the neon works when the over-ride switch is operated (and it doesn't consume any processor pins).

With multiple loads, each of 3 kW, you have an excellent setup.  The rev5 logic will activate as many loads as are required to consume the available surplus power.  If you have 7.5kW of SP, the first two loads will remain fully on and the third one will have a 50% duty-cycle. 

The first physical load is controlled at line 978:

          // update all other physical loads
          digitalWrite(physicalLoad_0_pin, physicalLoadState[0]);    

Similar statements for your additional loads would just follow on here.  The supporting logic is already in place, for as many loads as are defined at line 191:

const byte noOfDumploads = 2; // The logic expects a minimum of 2 dumploads,
                              // for local & remote loads, but neither has to
                              // be physically present.

I've posted a multi-channel simulator which you might find of interest.  I regularly use this to check out any new hardware; it's a bit more demanding than blink.ino.  The section for this sketch on my Summary Page reads:

FlickerDemo_multiLoad_2.   A max rate of change of surplus power has been added for realism.  Overflow and underflow of the 3600J energy bucket are now properly detected and displayed.  An ideal vehicle for playing around with different anti-flicker schemes.  Posted on 27/1/13 at http://openenergymonitor.org/emon/node/1637, this tool is available at
http://openenergymonitor.org/emon/sites/default/files/FlickerDemo_multiL...

Feel free to send me a PM if you get stuck.
 

Excellent, many thanks to both responders; that resolves my concerns.  I hope to develop some application specific algorithms to manage load priorities dependent on temperatures within the thermal store, hence my interest in clarifying how to modify the load drivers.  However, I suspect I need to read more of your web site before bothering you in future.

hello,

First of all i have to thank everyone in this mk2 proyect and specially Robin Emley.

i tried to read everything to do not ask things already asked, im trying to use the mk2 with several outputs, there is a old coment that says that robin edit a sketch managing 5 outputs, while the first 4 were in anti-flicker mode and the 5th when it turned on changed to normal mode. Im sorry but i cannot find that sketch anywhere. Even i tried to add those lines written up of my comment and i cannot control them with diferent energy divert. If someone could edit a sketch to be able to use the pin 9 as a normal mode and while the energy is growing start diferent pins 11, 12 with a relay 5vdc from arduino to start diferent watts machines and write a minimum of time to be working to avoid starts and stops.

In this forum i read that sometimes it exports a little, in my case every 5 minutes flash once, and as in spain they are going to look for the pv systems i would like change that correction to be consumed instead of exported.

Sorry that i cannot apport a lot but i will give it in the attacked photo is my version:

I am not a good programer so i couldnt calibrate the powercal, phasecal and other calibrations so i added potentiometer instead of resistors and with the sketch minandamch, range etc... i tune them to the maximum of the wave span and the ct to be in 512 exactly.

as you see in the right side is a supposed ACS712ELC-30A current sensor bought in ebay so its real a ACS712ELC-05B of only 5 amps, could i use it instead of the ct clamp? i know that the problem would be that all the current of the house pass thought that little cable but if manage to use relays i could use it only when the pv system is working during the day only and wont be importing more than 1kw.

Thanks in advice for any help.

Post edited by mod - Paul

hola euclapi,

It is always good to see a photo of some tidy hardware, especially if is running code that I have written!

My Mk2i rev5 code can control as many dump-loads as you wish.  All of these loads will operate in the same mode, either normal or anti-flicker.  If there is enough surplus power for several loads, then most of them will remain on continuously; only one load will cycle 'on' and 'off' to maintain the balance. 

The operation of this logic can be easily seen using a simulator sketch, which I posted on 27/1/13 on this thread.

In order to divert surplus power, the CT for your Mk2 PV Router must be clipped around one of the supply lines next to the meter.  It's not a problem if there is a large amount of imported power at certain times of the 24-hour period.  The processor will just ignore it.  When the sunshine returns, and the house starts to export again, your Router will spring back into life. 

There should be no need to ever switch the system off.

Hi euclopi, you are possibly referring to a sketch that Robin did for me some time ago that I then modified for my own use. I run battery chargers in antiflicker mode as my first loads and then further loads in a nearly 'normal' mode This sketch has now got somewhat more complicated with some 10 loads and with some loads timed with on delays and off delays. It is also more complicated with a sequence where my first 3 loads come on in sequence then they go off and 4 comes on. 1,2,3 then come on again in sequence and then 5 comes on and 1,2,3 go off and then back on again in sequence etc etc. 

Hi Robin,

First my congratulations on such a worthy enterprise,

I have created the mk2i using a breadboard atmega328 (uno bootloader) using the mk2i-rev5c sketch the problem I have encountered is that with no wires going through the Current sensor it is briefly firing the triac every few seconds; if I put a 60w bulb through the current sensor it stops or gets faster depending on the direction of the wire so it believes there is current flow when there isn’t.

If I use the mk2 mini rev 3 sketch with no wires through the sensor it displays a positive value fluctuating between 40 and 60.

I have created a circuit board with new components (except for the SCT013-000  and the transformer a spiratronics 230-9v-9v)  with exactly the same results and have even used a arduino uno in place of my breadboard atmega328 with the same results.

I have obviously gone wrong somewhere and have checked every connection and component but can’t see where the problem is so the questions is where have I gone wrong and where should I start looking for this problem?

Saying thanks in advance

Hi Paul,

Any measurement system of the type we use is likely to contain some residual error, or drift.  In my experience, it's never been more than around 1 Watt.  It all depends where the quiescent point for the current sensor lies within the ADC's input.  Over time, a small positive drift can disappear or become negative, but its magnitude should never be more than a Watt in either direction.

With an installed system, this level of background drift is not a problem, but on a test rig it can feel as though something is wrong.  If the dump-load in your test rig is only small, each firing of the triac will have very little effect, so the triac is likely to fire quite frequently.  If your load is a 3kW heater, then each firing of the triac is 60 Joules.  The Mk2i code prevents the triac from changing state on consecutive mains cycles, so each 'on' burst would be at least 100 Joules (with a 2kW load or greater).

If you run RawSamplesTool_4ss_2, the raw sample values from your sensors will be displayed.  With no current flowing, the samples for 'current' should show very variation.  If that sample stream is not stable, that would suggest your input circuit is not working correctly.  Are you using a buffered reference or the standard passive circuit?  These two circuits stabilise the signal in different ways  but they should both give very similar results, and minimal drift.

Hope this helps.

Re-reading your post, Paul, it seems that you're using a 3kW load already.  And the 40W offset using the "mini_3" sketch definitely doesn't look right.  Have you checked that your voltage and current sensors are using most of the available input range at the ADC?  My MinMaxAndRangeChecker tool can do this for you.  If your system is configured for 100A max, then it will not be able to measure the current that's taken by your 60W bulb with any accuracy - which could result in a high level of background drift.

On the Downloads Page of my new website, there is a calibration program which you could try running.  You'll need to reinstate the relevant pin numbers for your voltage and current sensor.  That cal program will display (via the Serial Monitor) the power that's flowing through the sensor each second.  I wouldn't expect it to give any different result than "mini_3", but various loose ends have been tidied up in this latest code.

It's also worth noting that the emonTx V3 design has paid close attention to screening, grounding and filtering to separate the digital and analogue parts of the circuit, and it performs significantly better than the V2 at low currents. If you have your own breadboard layout, it may help to look carefully at this aspect. There are useful application notes on the Atmel website.

I have recently fitted one of calypso_rae Mk2 Router systems and have to say I am very pleased with the system. I have a 170 litre hot water tank with immersion, though I do benefit from having mains gas too.

Throughout the enquiry and ordering process communication has been swift and very helpful. I purchased a completed system and it arrived within two days. The system looked quite impressive straight out the box, with all switches and lamps professionally labeled.

Install took a matter of an hour or so and then the system was up an running.

So in summary, can thoroughly recommend this system to all those thinking about  diverting energy to heat an immersion tank.

Hi Robin,

Thanks for responding, I decided to go ahead and complete the installation and check the supply meter in conjunction with my eco-eye energy monitor; the red anti creep led  on the supply meter remained lit even when the eco-eye monitor was showing an import of energy (from the bucket) so based on this  I would say it was working as you have designed, I just can not explain what I was seeing with my test rig, I will  order up another CT and check it out again when I finish integrating my modifications.

The stats from my eco-eye monitor will be incorrect as they will show transfers from the bucket as imported energy but a small price to pay for the extra hot water.

As an FYI my configuration is 12 SunPower SPR327 – 3.92kWp (9 SE facing 3 SW) Solar Edge SE4000-16 with P500 optimizers on each panel)  I also have installed 2 Solar Thermal panels which heat a 250 litre Hot water tank, the immersion heater heats the top third of the tank. http://www.kirkstone.me.uk/RMsolar/RMsolar-index.html

I was thinking of modifying your code to add a real time clock which would boost the top of the tank during the winter months first thing in the morning (I am on an economy 7  Tariff);  The Solastat controller (Solar Thermal) will call for a secondary boost if the temperature in the tank drops below a preset value, up to now I have used a clock timer and a big relay  to do this however  I would like  use the RTC to set a window to monitor secondary boost and if its active to trigger the triac, any pointers in how to do this or where would be the best place in your code to insert the new code would be appreciated. I am not sure the atmega328 will have the resources, but no harm trying, either way I have left enough space in the box to add another piece of circuitry as a plan B.

Photo shows today’s hot water boost to 75 Deg C

Regards

Paul

Paul,

When the Mk2 system is operating, the supply meter's LED is usually on, but not always.  If you turn on a high load such as a kettle to consume all surplus power, and then turn it off just before the next charge pulse is due, you'll most likely find that your Mk2 system springs into action while the LED remains off. 

During normal use, the LED is more likely to be 'on' if an AF regime is being used.  That's because the energy bucket needs to fill more than half-way before the output stage is activated.  If the router were to record each pulse at the meter during periods of consumption, it would then know precisely when the output could be safely turned on.  In that case, no loss of energy should ever occur and LED would never be continuously on.

The Eco Eye assumes that the mains voltage is a constant value, so that's once source of inaccuracy.  Also, I doubt if it measures energy flow continuously, so it is likely to be upset by bursts of power being diverted by a Router system.

I have no doubt that the Atmega will be able to do anything you ask of it.  With the interrupt-based code that you're using, the processor spends much of its time in the idle state. 

How best to operate a Router system alongside Economy 7 is very weather dependent.  On a good day, the router will provide ample hot water so its best not to pre-heat it with E7.  But on a poor day, the solar heating may not be sufficient in which case you'd end up needing to give the tank an end-of-day boost by some means that's more expensive than the E7 would have been.  My mum has exactly this dilemma with her thermal-solar panels, an oil-fired boiler, and E7.

In my latest Mk2 sketch (Downloads page on the website), I've provided a simple RTC function based on the periods when surplus power is available.  My "day" starts when the first burst of power is diverted, and ends 10 hours after the final contributon of the day.  That way, there's no setting up to do.  Whether the displayed total clears down at midnight or 4am is not of importance to most users.

Hi Robin,

I have the same problem as your mother which is why I topped up the tank with E7 an hour before the E7 period finished and if no solar during the day I kicked off the oil boiler early evening so I had one timer for the E7 and another timer for the oil boiler.

In your new code where you use a lcd display,  is  there some reason why you didn’t use a I2C LCD,  this only uses 2 wires SCL(A5) and SDA(A4) not only that you can have a multitude of devices on the same pair; for example  I run a 2 line LCD Dsplay and a DS1307RTC for a differential Solar Controller, using I2C freed up all my digital pins.

I'd never used any kind of display before so went for a simple persistence-based one.  Yes, it requires a lot of pins, but it does the job and takes up a minimum of processor time. 

With an interrupt-based sampling regime, and RF, I'd be rather wary about dropping additional workloads on the processor.  But maybe all these aspects have been taken care of and it would be fine.  With a PCB and ribbon cable, it's just as easy to wire up 12 pins as 2.

On my new board, if the RF facility is not required, all five of its driver pins are available at a SIL connector. These could then be used for other purposes.  Digital 3, the other interrupt line. is also wired to a connector point alongside a ground pin.

Hello all,

Just wanted to share with you my ATmega328 PV Dump configuration.

My requirement was a Mk2i PV Router to heat up the top of my hot water tank with any surplus going to an oil filled electric radiator in my office using the rf modules (RFM12B), I did not want to use an Arduino Uno in the units as it’s a bit overkill hardware wise as adding just a few extra components to an ATMega328p with an uno bootloader you effectively get an Arduino Uno. I purchased a CH340 USB to Serial adapter from ebay so I could program the atmega328 using the Arduino IDE.

The next hurdle was to find a circuit diagram; as previously mentioned in the forum there is no single circuit diagram to aid with this configuration; the information exists in various places on this forum and needs to be cobbled together. As my memory is not at its best I thought I would produce a set of circuit diagrams against future problems (Disclaimer: I believe I have incorporated the information from various sources correctly into my circuit diagrams, use them at your own risk) if you find an error please let me know and I will update them.

The only problem I had was that the RFM12B module in the Mk2i_PV_Router  was defective and there was no error message indicating a malfunction, very hard to debug as all the sketches rely on having two working units.

The Code I used was Mk2i_PV_Router_rev5c and RF_for_Mk2_rx 

Credit Goes to Robin Emley for this amazing project and Griff Thomas for his iphone psu idea which I used in the receiver, cheaper than buying the parts to make one (My circuit diagrams show a traditional ac-dc supply)

Regards

Paul

Paul: The only problem I had was that the RFM12B module in the Mk2i_PV_Router  was defective and there was no error message indicating a malfunction, very hard to debug as all the sketches rely on having two working units.

By this, I take it that the particular RFM12B module which you were using was found to be defective.  I'm not aware of any such defect in the design of my Mk2i_PV_Router!

To start with, when you have just two RF units, it is indeed difficult to trace problems when nothing seems to be happening.  I now have a dedicated receiver unit for both 433 and 868 MHz so can easily check any new boards that I build.  In due course, if I start to supply pre-built receiver units too, a similar approach will no doubt be employed.

On my latest version of the processor board, I've gone for 3.3V throughout rather than 5V.  There is therefore no need for a dropper stage for the RF module.

Robin,

Correct, it was a hardware problem with the RFM12B.

I know the Mk2 can handle multiple loads that are physically attached to it, the question is, can the code handle more than one RFM12B loads? if yes what changes would I have to make?

I went the extra mile using 5V for the ATmega328 rather than overclock (a good write up here :- programming-3-3v-atmega328-running-at-16mhz ); yes I know everyone does it but with my luck if I did I would be the exception.

Regards

Paul

I know the Mk2 can handle multiple loads that are physically attached to it, the question is, can the code handle more than one RFM12B loads? if yes what changes would I have to make?

Although I've never tried it, the answer is most certainly "yes".  You would just need to add an extra field into the message payload to convey the state of each extra load.  A byte for each new 'channel', or even just a bit, would be fine for this purpose. 

All of the multi-channel logic is already in place.  At the remote end, the receiver would just need to listen for its own instructions, and then turn its load on & off as instructed.

I went the extra mile using 5V for the ATmega328 rather than overclock

Until it was mentioned here recently, I'd not realised that using a 16MHz clock at 3.3V is outside the guidelines of the processor.  I've just bought a few 12MHz crystals and intend to have a play with these soon.    For most purposes, the slower clock speed should not be a problem.

In the case of my Mk2i code, the fixed timer would need to be extended in order to accommodate the increased duration that each ADC conversion would take.  That would result in fewer sets of samples per mains cycle, but there should be no noticeable difference in the system's behaviour.   

Thanks Robin,

Looks like I will have to order some more parts :)

Regards

Paul

Here is Revision 6 of the Mk2i code.  The two main upgrades from previous versions are:

1) the use of a second current sensor so that diverted power can be accurately measured;

2) the routine transmission of an all-integer payload via RF for use by emonCMS.  

In many ways, this version is more similar to rev4 than rev5.  Like rev4, it supports only one dump load, and has two energy thresholds for its anti-flicker algorithm rather than one.

Some items that were in previous builds are no longer supported.  These include the LEDs, the free-running mode of operation, Tallymode and phaseCal.   As the overall structure of the code has not changed, any of these features could be easily re-introduced if required.

A datalog file, with annotations, is also attached.  This data was captured yesterday using an emonTx-based rig while 'live' surplus power was being diverted.  The second column demonstrates how the average flow of energy at the supply point is zero.  Some photos of the rig are attached.

Similar code is available from my website as Mk2_RFdatalog_1.ino  That version also supports a 4-digit display for which two extra logic chips are required.  Together, the display and RFM12B use up all of the available IO pins which is why LEDs are no longer supported.  IMHO, a neon does a better job anyway, as shown in my recommended wiring diagram for Mk2 systems.

PS. If anyone would like to purchase this rig, it is available for £60 (or £45 without the two CTs).  With everything screwed down to the board, it is a fully working emonTx-based Mk2 Router with datalogging which will divert surplus power straight-out-of-the-box.   I would include a better heatsink and would replace the emonTx by a tidier one which has not been repaired.  Postage would be £5.  If interested, please send me a PM.

I recently started a new thread about how continuous sampling can become disrupted if the RFM12B module is used in a certain way.  In that thread, I reported that delaying the sleep command by a few milliseconds was a viable workaround. The library routine, rf12_sendWait() is a blocking function so is not suitable for code which needs to monitor continuously.

Since then, I have re-visited both the Rev5 and rev6 versions of my Mk2i PV Router code, each of which use the RF facility and require monitoring of the voltage and current sensor(s) to be continuous.  With the sleep command delayed, the outcome was better, but not perfect; RF transmissions do still appear to affect the underlying data to some extent.  The effect is somewhat variable, and I have not been able to pin down the precise cause.

Updated versions of each these code lines are attached:  rev5c has become rev5d (for controlling a remote dump load via an RF-link), and rev6 has become rev_6a (for datalogging via RF)

In each case, the RFM12 is now kept in an active state rather than being routinely sent to sleep.  I have also used the Jeelib routine rf12_sendNow() rather than rf12_sendStart() because it appeared to cause less disturbance to background powr readings.

For the Mk2-with-datalogging sketch, rev6a, I have inverted the sense of the transmitted data in order to align with the OEM standard.  Import at the supply point is now reported as +ve rather than -ve.  Diverted energy is still reported as being positive.  This change in convention can be seen in the attached results file. 

I am currently running a mk2 mini_3 router and need to upgrade to a multi load router with a primary load and secondary load. Has anyone managed to amend Robins mk2i rev5x sketch to allow multiple loads. Robin says that this can be done easily by modifying the sketch and removing the RF code but I am no programmer. If anyone does have this modified code, I would be eternally grateful if I could have a copy.

I don't quite understand what you want to do. Is it: Remove the code for sending the commands to the second load by radio, and substitute driving an output pin in exactly the same way as the first load is driven (but of course using the second load logic)?

Yes, Robert, I think that's the general idea.  To drive a secondary load by wire (rather than by RF) just requires another IO pin to be allocated and set up for this purpose, in exactly the same way as the first one.  Then, at the point where Load 0 is instructed whether to be on or off, Load 1 will be instructed likewise.  In my latest version of the Mk2i Rev5 code, which is rev5d, this is at line 991

// update all other physical loads
          digitalWrite(physicalLoad_0_pin, physicalLoadState[0]);

Although the Mk2i rev5 code has the logic for multiple loads, it also includes the capability for using RF.  If RF is not required, a tidier approach may be to use the equivalent code from my website, at www.mk2pvrouter.co.uk  

The sketch, Mk2_multiLoad_CAT5_2.ino  on my Downloads page supports several outputs for  wired loads but does not include any RF overhead.  This sketch is primarily intended to run on my own PCB, but can be run on any other Atmega 328 platform by just changing the IO pin allocations as necessary.

I was thinking of doing the change for 'thewaver', but as he's admitted he doesn't program, "full and final details to enable us to proceed" are in order!

I think everyone in this place should be prepared to have a go at modifying sketches for themselves.  It's the best way to learn.  If they run into difficulties, plenty of help is available. 

Ready-to-go Mk2 PV Router systems of various types are available via my online Shop.  These will be supplied with whatever software modifications (within reason!) that the customer would like :-)

"I think everyone in this place should be prepared to have a go at modifying sketches for themselves." Agreed, and recognising that this is for the most part a constructors' site, I have a reading list (which should be found with a search for "learning C++" - I've posted it many times) that will help. But unfortunately some seem to be daunted by the concept or haven't the time to commit to learning.

Hi Robert, you are spot on, I really don't want to learn to program at the age of 60 just so I can add a secondary load to an already working sketch. From what I have read in these forums, the coding is already in place but needs tweaking to get it to work for my scenario. I am using the arduino running on a pcb kit which I bought from this forum and using the mini_3 sketch. I have been told that the mk2i rev5b sketch could be easily tweaked to fit my request and all I asked was has someone already done this and would they be willing to help me with the programming. I am quite willing to pay for a pint or two for someone's efforts.

Don, as I mentioned yesterday, the sketch that you're looking for can be downloaded from my website.  Then you just need to change the IO pins to whatever you want. 

// allocation of digital pins when pin-saving hardware is in use
// *************************************************************
// D0 & D1 are reserved for the Serial i/f
const byte physicalLoad_2_pin = 2;  // <-- to control an additional load 
const byte loadPrioritySelectorPin = 3; // <-- this is the "mode" port 
const byte physicalLoad_0_pin = 4;  // <-- this is the "trigger" port 
// D5 is the enable line for the 7-segment display driver, IC3
// D6 is a data input line for the 7-segment display driver, IC3
// D7 is a data input line for the 7-segment display driver, IC3
// D8 is a data input line for the 7-segment display driver, IC3
// D9 is a data input line for the 7-segment display driver, IC3
const byte physicalLoad_3_pin = 10;  // <-- to control an additional load 
const byte physicalLoad_5_pin = 11;  // <-- to control an additional load 
const byte physicalLoad_1_pin = 12;  // <-- to control an additional load 
const byte physicalLoad_4_pin = 13;  // <-- to control an additional load 

// allocation of analogue pins
// ***************************
// A0 (D14) is the decimal point driver line for the 4-digit display
// A1 (D15) is a digit selection line for the 4-digit display, via IC4
// A2 (D16) is a digit selection line for the 4-digit display, via IC4
const byte voltageSensor = 3;          // A3 is for the voltage sensor
const byte currentSensor_diverted = 4; // A4 is for CT2 which measures diverted current
const byte currentSensor_grid = 5;     // A5 is for CT1 which measures grid current

At the age of 59, I can't be doing everything for everyone!

Hi Robin,

I have been studying your sketch, especially the section you have detailed above and I am not sure that I would only have to reallocate the digi I/O pins. My rig is wired as your diagram: http://openenergymonitor.org/emon/sites/default/files/Mk2_CircuitSchemat... and there seem to be differences in the AN pins between the mini_3 sketch and your new Mk2_multiLoad_CAT5_2 sketch.

It seems like you have pins AN1 and AN2 doing something different to the mini_3 sketch....or am I reading this completely wrong

I originally thought that I could replace my mini_3 sketch ith your Mk2_multiLoad_CAT5_2 sketch and change my current primary load from digi pin 9 (physical connection) to digi pin 12

'const byte physicalLoad_1_pin = 12;  // <-- to control an additional load',

and then add my secondary load to digi pin 2

'const byte physicalLoad_2_pin = 2;  // <-- to control an additional load'

If I do it this way, then I am assuming that I won't have to alter any of the code, or do I ??

It would be extremely helpful if you could show how the finished modified code would look to run my rig.

At 60 years of age, I dont think that I would be able to start learning how to program as my powers of retention are disappearing. I am guessing that you started to program many years ago and I do agree that you cant be doing everything for everyone. You have been really helpful in the past and guided me through the stages involved with enabling my PV system to operate perfectly with your mini_3 sketch, to which I owe you. Thank you very much for all your help and time.

Thanks Don

I think you're both spring chickens. I started programming with Fortran IV in the early 1980s, and I'm now getting to grips with Linux as an OS. I readily admit that it's easier to take on board a new one when you have met a few before, be they languages or OS's.

Robin's view is it would be safer for you to use the CAT5_2 sketch, and I'd support that, even though I understand that you have a working sketch and that you think you will feel safer extending that. 

The important things are the input pins and the output pins. Robin has changed the input pins around to suit his new pcb layout, so those will need changing back. That leaves the output pins. If you tell us which output pin you want to use for the second load, it's easy to tell you which lines of code to change.

Hi Robert,

Well, I certainly don't feel like a spring chicken, more like an old rooster!!

Thank you for your very kind offer:

My current rig running the mini_3 sketch is wired as the following diagram:

http://openenergymonitor.org/emon/sites/default/files/Mk2_CircuitSchemat...

You will see that my current load (will become primary) is connected to Digi pin 9. If there is no reason why it is not possible, could my secondary load be connected to digi pin 10.

I have already made the second triac circuit ready to operate the secondary load.

One question, when the primary load is satisfied and it 'flicks' over to the secondary load, will it revert back to the primary load if it demands 'topping up'?

Many thanks, Don...

When laying out my PCB, I found that it was better for me to use the higher numbered analog IO pins for the voltage and current sensors, as shown in the above fragment of code. 

My Mk2 code on the forum has always been configured to match the emonTx V2 which uses these analogue ports in a different way.  The voltage sensor, for example, has always used A2 rather than A3.  To get the Mk2_multiLoad_CAT5_2.ino  sketch from my website to work in this way, you would need to change '3' to '2' (twice) in the line:

const byte voltageSensor = 3;          // A3 is for the voltage sensor

Can you remind us what hardware you are running your sketches on. 

I am using the Arduino Uno with the complete kit and PCBs from RichMC, which I bought from this forum.

Thank you for your programmer tip. Would A5 need to be changed from A5 to A1 to match the mini_3 sketch ??

It details this on your schematic: http://openenergymonitor.org/emon/sites/default/files/Mk2_CircuitSchematic.pdf

const byte currentSensor_grid = 5;     // A5 is for CT1 which measures grid current

Many Thanks Don....