Archived Forum

just spotted this:

http://www.united-automation.com/f175-25a-filter-module-230v-25amp/

is it something that could be used if using it in phase angle mode to get round the RFI or am i looking at it too simply?

Looks perfect!

P.

Nice one.  I look forward to hearing how this EMC-suppression unit works with the phase-angle variant that I released a while back.  There was a lot of interest in phase-angle at that time, that being the obvious way to avoid flicker.  I wonder if anyone has actually tried that version yet?  According to my 'sticky' index, the details are:

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....

PS. With some sunshine today, I've just checked in the garage and our PV is generating around 1300W.  I assumed that the neon for the dump load would be flashing away as usual, but it wasn't.  Instead, it was lazily cycling on and off every few seconds.  "What can be wrong?" was my initial reaction.  Then I realised that this must be the anti-flicker mode, working for real.  Having previously said that I like my system to flicker, this alternative behaviour actually feels rather soothing - it's as if it is breathing.  If less surplus power were available, however, the system would no doubt look as though it's simply off.  A more complex a/f algorithm could perhaps combine the best features of both power-diversion modes.

As I'm yet to build either, though I have the parts on order, I'm not sure which way to go. Both probably!

I love the anti flicker mode as it enables the use of loads other than just heating elements or light bulbs. I was looking at battery chargers for one. The tumble dryer was another I was looking at- but that I may do with some internal modification. (heating element through MK2 and a voltage sensitive relay to give a full 240v supply to the controls).

I was also thinking of the 3 phase use of your designs. Looking at comments re the energy bucket in 3 phase meters I have come to the conclusion that the way to do it is just to put all the 3 live meter tails through the one CT. (It would mean unbalanced loads but in the context of 3Kw I don't think that's going to be a disaster).  

I have come to the conclusion that the way to do it is just to put all the 3 live meter tails through the one CT

mmm, don't think that's going to work. For one thing it would have to be an enormous CT to go around 3 meter tails and then there's the issue of the 3 currents being out of phase so you would just see the vector sum of the 3 currents.

The CT isn't a problem size wise, they are made in all sorts of sizes. the one Robin already uses would fit the 3 tails in.   The vector sum is what you want isn't it?

the one Robin already uses would fit the 3 tails in.  

I doubt that

The vector sum is what you want isn't it?

No. Imagine a point where 2 phases overlap with one negative and the other equally positive. The vector sum of these currents will be zero but both phases will be consuming power.

I doubt that

Just physically tried it and no they don't quite, you'd need the 1" not the 3/4"

Yes see your point on the vector sum, Same as putting the CT round the neutral.

Just been thinking, I have a 3 phase generator and that has a ct on each phase which then feeds into another electronic unit that shows the power to a single Kw moving coil meter.

A three phase system still has only one neutral, put your CT around that? Will that show the current summed?

Please read what i said again.

"Just been thinking, I have a 3 phase generator and that has a ct on each phase which then feeds into another electronic unit that shows the power to a single Kw moving coil meter."

I imagine the electronic unit is 3 rectifiers, averaging and summing to drive a d.c milliammeter or voltmeter. Basically, you need one wattmeter less then the number of wires. So for 3 phases and neutral you need 3 wattmeters. If you don't have a neutral, you need 2. For 'wattmeter' you can of course substitute a c.t and v.t to input to whatever electronic instrument you care to name. I know of no way to directly combine the outputs of 3 phase c.t's to give the arithmetic total of the currents, as distinct from the vector sum.

To get good results for 3-phase power, I take it that one would need to measure both voltage and current on all three phases (as Martin does with his 3-tier system)

If you have a 4-wire system, yes. If you have a totally balanced system and no neutral, two pairs of voltage & current measurements would suffice. (Blondel's theorem).

That's interesting.  The Wiki article appears to be saying that a single measurement of voltage is standard practice for 3-phase utility meters.  It was the need to measure voltage separately for each phase that I was interested in, because that will determine how much work a single Arduino would have to do. 

If voltage need only be measured once, then the total workload would then be only around twice that of a standard single phase system.  With approx 90 sample pairs per mains cycle for my Mk2a Router, that would give around 45 for a 3-phase system, which sounds feasible.  It would certainly save a lot of hardware if the output from all four sensors could be processed using just one Arduino.

Problem: how could the direction of flow be determined unless voltage is measured for each phase?  It probably couldn't :(

The Wiki article appears to be saying that a single measurement of voltage is standard practice for 3-phase utility meters

I don't think that's true for the UK as they wouldn't be able to meet the accuracy requirements. Both my house meter and the PV total generation meter definitely measure voltage on all 3 phases as they can both display all 3 values.

However, for diversion only the accuracy is not important, especially with a single threshold system, so 1 voltage measurement would be fine. In fact I don't think you really need to measure voltage at all for diversion only, even signal phase , all you need is a phase reference and an estimated voltage.

Once you have a phase reference for one phase you know the other voltages are 120 apart so you can determine their phase too. The PLL approach is ideal for this as you know the phase of every single sample.

It should be possible to design a 3-phase diversion only (i.e. no accurate power measurement) using a single, unmodified emonTX (or Robin's design with 2 extra CTs).

Having thought about this a bit more I think there would be an issue if the voltage changed between import and export, as it might well do since the solar voltage has to be higher than the supply. This would then create a bias in one direction or the other.

Thinking out loud here

"If you have a 4-wire system, yes. If you have a totally balanced system and no neutral, two pairs of voltage & current measurements would suffice."

I've only seen in the UK 3 phase Wye (star) with neutral are there any domestic/light industrial conditions that would allow an installation without a neutral as the load would need to be balanced?

Would there be neutral less systems outside of very specific applications in the UK?

So a system that looked at whats going through the neutral with software to identify each 120deg of phase difference could calculate total load.

The only instances of systems without a neutral in Wye or delta configurations I've seen have been on board R.N ships and submarines.

So a system that looked at whats going through the neutral with software to identify each 120deg of phase difference could calculate total load.

What will that tell you? Look hard at the animated diagrams here and think where the currents circulate.

Yes i see  you need to monitor voltage and current on each phase and calculate the power from there and add the three together. Is it not possible do this from the neutral line?

It's a long time since I looked at three phase!

However, for diversion only the accuracy is not important, especially with a single threshold system, so 1 voltage measurement would be fine. In fact I don't think you really need to measure voltage at all for diversion only, even signal phase , all you need is a phase reference and an estimated voltage.

Whether or not to measure voltage when calculating power/energy is a moot point.  When surplus power is to be diverted, a measurement of the voltage allows the direction of flow to be determined, so I have always thought it sensible to use the voltage sample stream to improve the accuracy of the calculated value.  Some systems, such as the Eco Eye, only use a nominal value for voltage.  In that case, the direction of flow is detected by using a capacitive sensor that's taped to the Live wire.

Producing values for voltage that are offset by 120 degrees will be interesting.  Perhaps this could be done using a set of sinusoidal samples stored in an array.  By determining the RMS value of the voltage on one phase, all samples taken from the array could then be calibrated for the actual voltage at that time.  The necessary phase-offsets would be achieved by selecting the appropriate index from the array.  Using a PLL, with a fixed number of samples per mains cycle, would be convenient for this, preferably divisible by 3.  51 maybe?

With four analogue sensors on the go, processing time would be at a premium.  My fastest Mk2 code to date has just been posted at http://openenergymonitor.org/emon/node/1912   By allowing the ADC to be free-running, and using interrupts to co-ordinate its activity with that of the main processor, around 95 sample pairs per mains cycle is achieved.  The same code can also be run using a fixed rate timer for the ADC.  
   

I suggest that for accuracy, especially as it has been shown that a 3-phase digital meter behaves in exactly the same way as an analogue one, i.e. export on one phase can balance import on another, then it is necessary to measure both voltage and current on each phase. Some assert that the voltage on the 3 phases is always the same, and that the phase-neutral voltages are always 120° apart, but in the real world this simply isn't true. Whether it is an acceptable approximation is a different question that can only be answered when you know how significant the error will be. Bear in mind that if you don't measure a voltage, because power is proportional to voltage², the power error will be very nearly twice the voltage error.

Although I've never taken any formal results, my readings of power taken with an Arduino rig do appear to change by several percent at different times of the day.  Similarly for the mains frequency.  With a 125uS hardware timer, the build I've been working on recently has sometimes recorded 80 sample pairs per mains cycle, as expected, and sometimes only around 78.5

If the only purpose of the exercise is to identify and divert any surplus power, then it is probably less important to measure voltage.  Because the system is always aiming for the condition where import and export are balanced, it is only the reduction in the voltage value that is caused by the triac turning on that is of importance.  Changing the absolute value of the RMS voltage will have minimal effect because the import and export power values will both be increased by the same amount and cancel themselves out.

When decent weather returns, it would be interesting to see how a Mk2 build behaves if only current is measured.

The short-term frequency stability is at worst +/- 1% (0.5 Hz), but the long-term is a whole lot better and I believe that it is checked against the national standard of time held by the NPL, so that clocks that count mains cycles do not drift from day to day.

If you install MartinR's PLL controller, you can watch the frequency change over the course of a day, dropping at times of high demand and rising when demand is low. Or you can go to the National Grid website to get up to date data.

If you install MartinR's PLL controller, you can watch the frequency change over the course of a day, dropping at times of high demand and rising when demand is low. 

Alternatively, I can simply check how the number of samples that I'm seeing per mains cycle drifts during the day.  My Mk2x PV Router code already displays this information in its calibration mode.  With a fixed ADC timer rate of 200uS, there will be around 50 pairs of samples per mains cycle (the same as Martin's PLL code).  As the mains frequency varies, so will this number.  Both methods rely on the stability of the Arduino's clock, so are equally valid.

(Sorry if this sounds a bit grumpy.  But this is my thread, and my code works just as well, IMHO!)

Robert, this is a great website if you're interested in power stats:

http://www.gridwatch.templar.co.uk/

(e.g. look at the weekly Nuclear/Coal/Gas graph - it demonstrates in just a few pixels how important the controlability of gas is to our energy mix. Nuclear is on and constant. Coal can be controlled a bit, but only slowly. But gas is what allows the supply to match the demand (and by doing so, I guess, keep the frequency needle close to 50Hz).

Sorry Robin, your code is brilliant. Your thread is brilliant. etc. etc. etc.

P.

Alternatively, I can simply check how the number of samples that I'm seeing per mains cycle drifts during the day.

It's not really the same though Robin. The PLL technique is capable of measuring the period between zero crossings to within one 16MHz clock period.

It's probably not important but I also believe the Arduino UNO uses a ceramic resonator which won't be as accurate as the crystal used on the emonTx.

If we're going down that route, I ought to have added "subject of course to the accuracy and stability of your frequency reference".  µP crystals tend to be cut for best short-term jitter, not long-term stability, so aren't inherently "best" for stable frequency measurement.

I guess you could calibrate it by counting the number of mains cycles over a period of several days, as (as I wrote above) I believe the grid is over time locked to the national time standard. You'd need to time for well over 2 years   before you broke a 32-bit integer value, so do-able, but I'm not volunteering. Also, you'd need to be well clear of auto-reclosers and other momentary switching breaks, not to mention longer supply interruptions. You'd presumably need one of these, too. Oh, and anyone who complains that this suggestion is outrageous hasn't got a working tongue-in-cheek detector.

A much more sensible way to calibrate would be to log the frequency you read and compare afterwards with the published national record.

(I simply named MartinR's sketch because it outputs the frequency as a number - e.g. 49.98 - directly comparable with the published data).

Not so tongue-in-cheek Robert, I already have one of those PV Electronics MSF receivers in my system to distribute time...

OK guys, thanks for the feedback.  I'm probably about to get out of my depth here ...

Recording how the mains frequency varies during a 24H period might be a fun thing for my spare rig to do.  Without easy access to 'standard time', I would not wish to report any absolute values, but I would hope that my results would track those of the National Grid pretty closely.

You stated, Martin, that the PLL technique is capable of measuring the period between zero crossings to within one 16MHz clock period.  Given that the CT is essentially ac-coupled, I'm intrigued that you feel able to make such a claim.  How can you know to such precision when these elusive zero-crossings occur? 

Or maybe you are saying that over a suitable period of time you can determine the average duration of each mains cycle to this accuracy.

Is your issue that the DC offset might not be perfect? If so, it doesn't matter, so long as you measure time between the same point in the mains cycle each time the frequency will be accurate. Also, don't forget we are talking voltage here where the asymmetry is nowhere near as bad as it can be for current.

I do average the frequency for display but only because there's lots of cycles between prints.

Is your issue that the DC offset might not be perfect? If so, it doesn't matter, so long as you measure time between the same point in the mains cycle each time the frequency will be accurate. Also, don't forget we are talking voltage here where the asymmetry is nowhere near as bad as it can be for current.

Yes, I agree with those points, Martin.  I was just responding to your specific claim that "The PLL technique is capable of measuring the period between zero crossings to within one 16MHz clock period."  

By "zero crossing", it seems that you you actually mean "any fixed point on the waveform".  This is presumably after the standard HP filter.  The signal from your voltage sensor will only remain fixed DC-wise if conditions in the vicinity remain constant.  If my Bosch hot air gun were to be switched on nearby, or Jack's wife' s hair dryer, your voltage waveform  would undoubtedly shift up or down a bit.  Easy to detect no doubt with the level of accuracy that you have at your disposal.

First results from my mains checker sketch suggest that our 50Hz supply pretty much spot-on.  With a fixed rate ADC timer of 125uS, I would expect to see 480K voltage samples per minute:

-------------------------------------
Sketch ID:      MainsFreqChecker.ino
ADC mode:       125uS fixed timer
Extra Features: none
one period has passed, sample count = 480331
one period has passed, sample count = 480757
one period has passed, sample count = 481335
one period has passed, sample count = 480688
one period has passed, sample count = 480660

In practice, I expect that some processing cycles will be lost between each ADC operation.  At 8pm, the mains is probably running slow, hence the higher numbers that I'm seeing.  In due course, I hope to leave it running for 24 hours and then plot the results.  Any trends will hopefully align with published data. 

>I also believe the Arduino UNO uses a ceramic resonator which won't be as accurate as the crystal used on the emonTx.

My UNO r3 has a crystal. 

As regards 50Hz mains drift.  I understand accuracy over a period of time is maintained acurately.

My UNO r3 has a crystal.

That will be for the USB-UART chip. If you look near pins 9 and 10 of the ATMEGA you will see the little ceramic resonator for the processor.

Hi Martin

Hmm, metal cased device but with 3 smt pads reminiscent of a resonator but seems to have 2 smt caps to ground.  Official Arduino website schematic for UNO R3 has crystal with caps as clock for Atmega328p. My dim and distant recollection of RS232 specification was the 1% baudrate discrepancy was well within the RS232 spec and  resonator should be well with this %.  Curious why USB Uart would have crystal yet clock for MPU would have resonator.  Must be more to it.

I stand by my claim that 50hz mains frequency is/was tightly controlled.   I have a friend who was technical salesrep selling power station control installations from GEC, to all over the world.   They certainly used to control and correct it accurately over a period of time but who knows what commercial pressures dictate these days.

Anyway, lets not get sidetracked from the focus of this forum.

Laurence

Hello

I'm new in this forum, just read everything and it's all very interesting and I'm thinking to build the MK2

Just have a doubt, we in Spain have 50Hz  230Volt but  2x120Vphase system and no neutral, will the MK2 work here?

Thanks

Just to clarify, you have 2 line feeds, each measuring 115 V to earth and 230 V line to line?

I don't see why not. You measure the voltage between lines (230 V) and the current in one line only. You install your triac in one line only, but caution - the immersion heater is live even when the triac is off.

Thanks Robert

Today I build it but it's not working, I tried with a bulb connected on the triac, it triggers the triac only to on or off, in debug mode the triac is working fine.I don't know what to do?

Here is the serial output

in NORMAL mode ...

cyc# 5, sampleV 378, fltdV 11.00, sampleV-dc -141, cumVdeltas -1751.89, prevDCoffset 537.36, refFltdV 519.84, enInBkt 0.00
cyc# 505, sampleV 523, fltdV 26.55, sampleV-dc 13, cumVdeltas 16.92, prevDCoffset 508.84, refFltdV 509.01, enInBkt 0.00
cyc# 1005, sampleV 524, fltdV 27.50, sampleV-dc 14, cumVdeltas -10.34, prevDCoffset 509.14, refFltdV 509.03, enInBkt 0.00
cyc# 1505, sampleV 504, fltdV 6.78, sampleV-dc -5, cumVdeltas -24.09, prevDCoffset 510.08, refFltdV 509.84, enInBkt 252.34
cyc# 2005, sampleV 518, fltdV 21.20, sampleV-dc 8, cumVdeltas -41.82, prevDCoffset 509.93, refFltdV 509.51, enInBkt 1590.04
cyc# 2505, sampleV 516, fltdV 19.83, sampleV-dc 7, cumVdeltas -3.31, prevDCoffset 508.96, refFltdV 508.92, enInBkt 3600.00
cyc# 3005, sampleV 522, fltdV 25.82, sampleV-dc 13, cumVdeltas -19.39, prevDCoffset 509.06, refFltdV 508.86, enInBkt 3600.00

The first 3 lines are with no inyecting to the grid the last lines is with inverter turned on, the triac turns full on or off at the right moment bur without flickering.

That look right what are you actually measuring with the CT? My test rig is a heater with the CT around the live lead and as you have the triac powering a bulb. In debug the light will switch on and off (as you noted). with debug disabled if you then put the CT round the live of a heater etc and switch on the bucket will fill till the lamp comes on and will stay on till you reverse (phisically) the CT on the lead. If you just switch off the heater the bucket stay at the same value and the light will stay on.

When you wire the system into the "real world" you will have a feedback loop

sun comes out - bucket fills and fires the triac - bucket empties slightly so the triac switches off - the sun tops up the bucket so it switches on.

The system needs the feedback to switch the triac on and off.

from what I can see your system is working.

Yes, I agree.  That display looks fine.  Now you need to run the sketch in normal mode (without the #define DEBUG line), and pass one core of the cable which supplies you your load through the CT.  You will then have some feedback so the load should flicker. 

I've posted a couple of videos about this, as listed on my Mk2 summary page (the top entry in the General forum area).

You may find the Mk2_PV_Router_mini.ino sketch a bit easier to follow.  It's a lot smaller than the original one.

Can I go back to first principles and confirm that that the correct way to calculate power is:

Take current and voltage samples many times a mains cycle, giving the samples I1, I2.… and V1, V2….

Real power = (I1 x V1 + I2 x V2 ………)/number of samples

RMS current =  SQRT ((I1^2 + I2^2 + ….)/number of samples)

RMS voltage = SQRT ((V1^2 + V2^2 + ….)/number of samples)

VA = RMS voltage x RMS current

Power factor = Real power/VA

Does this also work if there is large voltage to current phase shift caused say by heavy inductance or capacitance in house loads? I think it should because, if say there is a 90 degree current shift on pure sine waves, the above real power will be zero but the VA will be normal sized.

And is this exactly the same method used by digital utility meters? I ask because if say you use phase control there is heavy distortion of the mains current caused by the non sinusoidal current and the ringing caused by the sharp current transitions. So the solar diverter has to use the same calculation method as the meter or else a balanced condition on the diverter will not equal 0W on the meter.

I am ignoring here any approximations caused by the sampling not being an infinite number per cycle and any voltage phase shift if you use a transformer to sense voltage.

I do wonder if wheel meters are quite so accurate in making this measurement as I suspect they are rather assuming the waveform is sinusoidal.

This all looks OK to me, but I'm no expert!

(I presume that "VA" is the same as "apparent power")

"I do wonder if wheel meters are quite so accurate in making this measurement as I suspect they are rather assuming the waveform is sinusoidal."

They were invented many many years before light dimmers, drill speed controllers, switched mode power supplies etc. that do very odd things to the current waveform, so I guess not. And the volt sense transformer is being used at minimal current draw so distortion will be minimal and phase shift can be compensated for. 

A 90deg phase shift would be unlikely although I wouldn't mind a 180deg phase shift on my major appliances though my energy supplier would be a bit miffed!

Yes eureka system is working fine after connecting the load of a 2Kw heater.

Our problem here in Spain is that electricity companies have programmed their digital meters to sum the exported energy on your bill, they see PV energy as a competition on the market and do everything to kill it.

OUCH!  There's a distinct lack of understanding of basic principles in some of the above posts.

1. VA (Volt.Amperes) is the same as apparent power. There's Power (real power), the quadrature component is reactive power (I was taught 'imaginary power' which is a much more self-explanatory term) or vars (Volt.Amperes reactive), and the resultant of those two is apparent power (V.A) which is what you get when you read an ammeter and a voltmeter and multiply the two numbers.

2. Phase shift doesn't affect the maths because there are no approximations in there. It might well affect your ability to measure it accurately though without the right gear.

3. An induction/Ferraris/disc meter does the multiplication by the magnetic field acting on a current. So it is pure physics. If you do the theory, the only approximation is the current in the voltage coil isn't quite at 90° to the voltage (because you can't have a pure inductance without some resistance), so the magnet has a shading ring fitted to correct this. You'll find that the equation for torque doesn't have a frequency term in it, so harmonics don't enter the picture. (But note, that doesn't meant that this type of meter will work on d.c - it won't!)

My latest creation

Very neat, Markus.  Any chance of a photo to show how the triac and heatsink are fitted?

Nice looking PCB.  Are you able to supply these for others to use too?

Was there a reason in the main design for not using a packaged solidstate relay with zero crossing opto isolation built in?

They are so cheap on ebay now and would do away with one of the pcbs in the two board solution.

Bob

Was there a reason in the main design for not using a packaged solidstate relay with zero crossing opto isolation built in?

Not really.  As soon as I saw Paul's video of a triac silently switching a lamp on and off, I knew that's what I wanted to do.  By using a standard triac and trigger, I was able to forget about the HV side and concentrate just on LV things.   

If the trigger and triac are in the same package, why would that affect the pcb?  240V still has be present on the board somewhere.  Or would you be wiring direct to the pins of your SSR?

Was there a reason in the main design for not using a packaged solidstate relay with zero crossing opto isolation built in?

They are so cheap on ebay now and would do away with one of the pcbs in the two board solution.

The logical extension to that question is why not use an emonTx instead of a Uno and get rid of both PCBs? That way you also have the option of adding wireless monitoring if you want to. A 3V SSR plus an emonTx is all you need.

That's not to take anything away from Markus's design, that's a very professional looking solution - well done!

The logical extension to that question is why not use an emonTx instead of a Uno and get rid of both PCBs? 

I had two reasons for not using the emonTx:  i)  I wanted my 2.5V Vref rail to be buffered and shared, and ii) I already had a pair of Uno R3s.  

An emonTx has no space for output circuitry, so some kind of mounting would still be needed for the SSR and any associated components.  Or is the idea that the SSR is mounted on a heatsink, as per the triac, with control wires coming straight from the emonTx?

The buffered reference is a valid point but I don't think it's very significant. You can get remarkably accurate results from a standard emonTx.

Most SSRs have a built-in heatsink so you would put that safely away somewhere and just run the low voltage wires to the emonTx.

It may even be a cheaper solution if you have to buy everything??

Hi,

I have an SMA Sunnyboy 4000TL in an offgrid property in Wales. In conjunction with a SMA Sunny Island 2224 Inverter/Charger, it supplies our house with 240ac and charges a 24 volt dc battery bank.  The System regulates overproduction during periods of low load by using Frequncy Shift Power Control (FSPC). When the battery is full and there is no load but lots of sun the Sunny Island raises the grid Frequency from 50hz to 52 in 0.1hz increments. At 52hz the Sunnyboy produces 0 power to prevent overcharging of the battery.

I'd like to modify Robins design to use frequency rather than current as the control input to activate an immersion heater....trouble is I have no idea what im doing!

 I have very limited experience of programming Campbell Scientific data loggers and have bought an Arduino Nano starter kit and have learnt (copy and paste) how to program some button controlled LED programs. 

 It seems to me that it wouldnt be too much of a leap and hoped some of the brain power in this forum could help me out or suggest some reading.  Am I right in understanding that the Triac is efficient by literally allowing an unprocessed AC wave through or not. So if there was 1kw of excess pv and you had a 2kw immersoin heater it would let through 50% of the ac cycles?

The only thing I can bring to the table is the concept that this could be developed into a commercial product for Offgrid installations that use FSPC....

Any feedback much appreciated.

Will

Bob

Yes exactly that, most SSRs come with two hefty screw terminals for the power and 2 smaller screws for the drive which can easily accommodate the series resistor so direct connection to the processor and no PCB needed.

And the price tag?  My triac and trigger come to around a fiver.

Your software seems so refined now that I'm unlikely to be able to make an significant contribution to it.

There's always room more more refinements!  When re-connecting my rig for today's sun, I moved my selector switch for the Immersion to "constant" several times.  On each occasion, consumption started to register at our meter.  After turning the selector back to "PV only", power distribution (in anti-flicker mode) started up again shortly after.  All just as expected.

On each occasion, while the router's energy bucket was charging up, the meter's LED went on thereby showing that some surplus power has been lost.  This is an unfortunate consequence of the router not knowing the state of the meter's own "bucket", or equivalent.

If the router were to monitor the meter's LED events, and update the level in its own energy bucket accordingly, alignment between the two systems could be maintained at all times.  No more energy need ever be lost whenever the system starts up after a period of export.

This is a limitation which I hope to fix before too long.  But it's also an open challenge to anyone else who may be interested ...

If the router were to monitor the meter's LED events, and update the level in its own energy bucket accordingly, alignment between the two systems could be maintained at all times.

That doesn't sound very difficult. Isn't it just a matter of setting the energy bucket to full when you get an interrupt from light sensor? I had a play with detecting the meter LED for my ICAL calibration tool and it's pretty simple to do.

Hi Robin

I just  glued the heat sink with heatproof silicone.

Today I've tried about 10 hours with a 4,5Kw load and heat is around 50-55ºC on heat sink. Traces on print for load are  traced on top and bottom of pcb, it is designed to hold 30A

About if PCB is available, yes it's possible will be around 20€, I have made 5 PCB (absolute minim) by a 6 hour quick service and it have cost me 43€ each, to get discount I've to order at least 50 pieces.

And the price tag?  My triac and trigger come to around a fiver.

And the PCB?

About half your price here http://tinyurl.com/ac2stf7 

£2.55 including P&P from Hong Hong

I put one of this type into a kiln controller recently without drama. They take about 3 weeks to arrive but I just can't think how they can post them around the world to that price.

Bob

That doesn't sound very difficult. Isn't it just a matter of setting the energy bucket to full when you get an interrupt from light sensor? 

Indeed it is.  But if you do nothing else, then the triac will come on straight away because the bucket is full.   The algorithm for turning the triac on will need to be a bit smarter. 

There will also be a delay before the meter pulse can be confirmed, so the bucket's level will ideally need to be adjusted by however much energy has flowed since the start of the pulse.  Not every off-> on transition is the start of a pulse.  Periods of exporting and anti-creep both start in this way. 

And although it doesn't look like one, an on->off transition means just the same as a pulse; you have just been charged. 

I prefer to use the SSR as no pcb is needed and mains connections are direct to it.  I'm using these:

 http://uk.rs-online.com/web/p/solid-state-relays/7360867/

Not cheap but a quality item. The SSR is Zero crossing and has very little heat output. The input current is also very low so no resistor is needed.

One thing to note though is that the input is reversed- ie high is on. To me this is the way it should be and not high is off, especially as I have mine mounted remotely, about 75m away, and therefore any break in the control cable would not result in the loads being on.

I'd like to modify Robins design to use frequency rather than current as the control input to activate an immersion heater....trouble is I have no idea what im doing!

I have Sunny 5000 backups for my system. To use Robins system have you thought about using a frequency controlled relay to turn it on. As the frequency rises to limit the output of the inverter the relay could be set to turn on the supply to the Triac / SSR.

I bought this one on ebay

  http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=200839603252&ssPage...

You would also need to put a delay timer in to stop the relay cutting out as the frequency dropped when the loads came on.

Another option is I think the SB2200  has a relay within it that can be set using different parameters eg. battery state of charge so you could use that to control a large relay for the triac/ssr supply.

willatpenru

You could also look at Martin's PLL design, which measures the frequency on-board. It uses the same basic algorithm for load control. There's not much point in buying an add-on relay if you can do it on the software.

Yes,thanks Robert.  The PLL library I posted here will give you frequency too.

How will you know when to turn the load off once the frequency drops though?

How will you know when to turn the load off once the frequency drops though?

Its not just that- you also have to be careful that the sunny backup doesn't start using the batteries to power the controlled loads.

I'm not sure if I am the only one to be using Robins sketch in anti flicker mode but I have noticed something that is very important.

Robin mentions, how with anti flicker, it is vital to get everything calibrated spot on. Despite doing all that I still couldn't get the led on my electricity meter to stop registering consumption. Eventually through trial and error I managed to find calibration values that worked pretty well but they weren't anywhere near where they should be. The conclusion I reached was that my meter didn't have an 'energy bucket' of 3600J.

I need to run the anti flicker mode as I use multiple battery chargers, switched in sequence, to charge my batteries up with the surplus PV.

Today was the first time I have had some time available to test that theory and to cut a long story short I've found my meter has an energy bucket of only 1250J. This meter is an ACE1000 which can be manufactured either by Itron or Landis & GYR.

Is anyone else using anti flicker?

The brochure for the meter says both the meter constant and the auxiliary contacts are  800 pulses per kWh. I would have expected the 'energy bucket' to be 1.25Wh or 4500 Joules from that so 1250 Joules is surprising.

Yes that was my thought as well but it certainly isn't. You can run a 500w load for 2.5 seconds without it registering but try it for 2.6 seconds and in this case the green led on the meter goes off and the red led will pulse.

It might be worth getting another meter and checking it on the bench just to make sure that yours isn't faulty. They're only £11 from UMS here.

I had my system connected to the DNO meter and that's when I noticed the calibrated values didn't work with it so I purchased a meter to bench test from the company you mention.

The values I had found worked using trial and error on the DNO meter were a powercal of 0.15 using an energy bucket of 2800J (I had assumed worst case and reduced the 3600J to 2800J as my meter is only 800 pulses, wrong way round I know, but I was frustrated and wanted to use the worst case I could possibly think of).

My tallymode my powercal should be 0.067

interpolating;

(2800/1250) = 2.24 multiply that by  0.067 gives the 0.15 that I’d got by trial and error.

So both meters give the same result.

Tinbum

I have the same meter. I tried the AF MK2i rev 4 and found that I could not get it to work as intended without getting a charge pulse. So I'm back in the normal mode. I don't have an issue with flickering lights but wanted to have a play with the AF mode.

I'm also fairly confident that my MK2 is calibrated well and works just fine in normal mode!

Mark

Digital meters appear to have different ways of accommodating reverse flow.  In the standard case, the whole of each 1 Wh window is available for reverse flow.  Providing that your A/F measures remain  within this range, and the router's energy bucket never under- or over-flows, you should be OK. 

During periods of consumption, some meters pulse less frequently than once per Wh.  One might be tempted that this larger window is therefore available for retrievable reverse flow, but that does not seem to be the case.   I think what's happening here is that every time the green LED goes off, some charge is being registered.  After N iterations, a red pulse appears.  But if the oscillations are kept sufficiently small that the LED never goes off, then no charge is levied, hence no pulses. 

It would be very interesting to know whether N is constant.  In other words, does the red pulse always occur after the same number of consumption cycles, regardless of whether the timer is set to 2.6 seconds or 2.8 or 3.0?   My hunch is that it will not make any difference.

While surplus power is being actively diverted, I think it's OK for the led to be either constantly 'on' or 'off', but it should definitely not be cycling on/off in time with the load operation.  If this is happening, then I feel sure that you will be wasting power and also being charged for the privilege!  Definitely something to watch out for. 

Operation outside the sweet zone can be easily checked by adjusting the cal factor so that the router under-reads.   If using twin energy thresholds that are 0.8 Wh apart, I would expect normal service to be maintained until the calibration is out by around 20% (or 25% for the purists).  After this point, the LED's behaviour will noticeably change.  This kind of experimentation allows the margin of safety to be determined directly, but the results do need to be viewed in the light of the prevailing conditions, both weather and base-load.

An interesting observation. I'm trying to figure out the significance of 4500 / 1250 = 3.6. Moreover, what I don't understand is how you get an indication after 1250 J when the meter constant equates to 4500 J? Are you saying that the first pulse after export comes after 1250 J, then the next (continuously importing) after a further 4500 J, or is your meter constant 2880 pulses per kWh and not 800 as specified?

One thing is certain: your 'anti-flicker' won't be as effective as it would otherwise be.

Hi Mark,

I'd be interested if you could  try it in antiflicker with the energy bucket at 1250J instead of the 3600J and see if it works then. I'm certain it will.

Nick

Will do but my free time when the sun is out is at weekends only. So let's hope we have enough excess at the weekend to give it a try.

Mark

Are you saying that the first pulse after export comes after 1250 J, then the next (continuously importing) after a further 4500 J, 

If I may venture an opinion, I think the answer is yes, but they are two different types of pulse/event.

With most meters, the LED going off is essentially the same as a 1 Wh pulse, although it doesn't look like one.  In the case of this alternative type of meter, it is only the 'big' consumption pulses that are normally seen (red led).   Its 'mini' consumption events are not normally seen because the green LED is normally not on during periods of consumption.  They can only be seen when repeating periods of reverse flow exceed the capacity of the mini window, which appears to be around 1250 J.

My hunch is that there will always be the same number of mini charge events (green led, on->off) before each red pulse is seen.  It will be interesting to see whether the number of cycles per red pulse is affected by the duration of each period of consumption.

But that's only my prediction ...

I will try and find time to do a bit more testing on this meter and count the green pulses before a red and also try with different loads, but I'm really busy at the moment.

Re. antiflicker not working so well with such a small energy bucket, very true, which is disappointing, but thankfully my loads that have to run antiflicker are only 1Kw each.

Robin very kindly wrote me a multiload sketch so I have 5 triacs controlled by the Arduino. 

4 1Kw loads (battery chargers) are turned on in sequence depending on the available PV using antiflicker mode. The 5th Triac is to the 3Kw immersion element which won't run well on antiflicker with this meter. I have now adapted the sketch so that when the 5th triac turns on the mode automatically changes from antiflicker to normal. This will have no effect on the first 4 loads as they are already all on constantly. Should the PV then drop the mode will change back to antiflicker. Just waiting for the sun!! 

.

If you only have 1 kW loads, it might be worth recording the voltage dip when you switch the load. If it's less than 0.3%, you don't need to worry about it.

Harmonics and Flicker - the low frequency end of the EMC spectrum
By Dr. Philip D Slade, Exeter University
http://www.compliance-club.com/archive/old_archive/990619.html

1Kw loads (battery chargers) are turned on in sequence depending on the available PV using antiflicker mode. The 5th Triac is to the 3Kw immersion element which won't run well on antiflicker with this meter. I have now adapted the sketch so that when the 5th triac turns on the mode automatically changes from antiflicker to normal.

The extent to which anti-flicker measures can be usefully applied is dependent on the meter, not the load.  If a simple 2-threshold A/F scheme works with your meter when running a 1 kW dump load, then it should also work for a 3 kW load, or any other rating for that matter.   The "sweet zone" of the meter is the same regardless of the load. 

For most meters, this value of this usable zone is 3600 J.  Because yours is less than this, around 1250 J, your upper and lower thresholds will need to be closer together, maybe 1000 J apart. 

Make sure that you don't have any timing criteria in there.  My A/F schemes to date have generally had a feature that prevents the triac from switching on or off within a certain period after the previous transition.  You could either remove this logic, or set the value of this period to zero.

The benefit of A/F becomes progressively greater as the rating of the load is increased.  It makes little sense to me for A/F measures to be in place for small loads, but absent for larger ones.

If you only have 1 kW loads, it might be worth recording the voltage dip when you switch the load. If it's less than 0.3%, you don't need to worry about it.

Hi, yes I see the reasoning but I'm not running it in the A/F mode because of flicker its actually because of the type of load.

Anti-flicker mode affects the rate at which flicker occurs. It has absolutely no effect on the voltage dip - none whatsoever. Your logic seems more than a little topsy-turvey to me and I think you need to stand back and think through how the algorithm actually works, and how the controller interacts with the meter, and how your loads interact with the electricity supply. You'll find the complete write-up by Robin here and something about meters here.

Anti-flicker mode affects the rate at which flicker occurs. It has absolutely no effect on the voltage dip - none whatsoever. Your logic seems more than a little topsy-turvey to me and I think you need to stand back and think through how the algorithm actually works, and how the controller interacts with the meter, and how your loads interact with the electricity supply. You'll find the complete write-up by Robin here and something about meters here.

Sorry but my logic is totally sane and i know exactly what i am doing. What is it with this forum, new members come along and they just get slated.

You mentioned voltage dip not me. The normal mode is good for resistive loads, my battery chargers are not resistive loads.

To be perfectly honest I think Im just going to leave the forum.To be blunt I now have a system that works perfectly and you can just go on and work out the rest for yourselves.

Voltage dip, more specifically the perception of the effect of dip - flicker - is the reason for the regulations concerning the rate at which you can automatically switch a load. Any load. That's why I mentioned that if your dip was less than 0.3%, you had no need to concern yourself with flicker. Otherwise, if the combination of dip and switching frequency falls inside the area where it has been shown to cause annoyance, the electricity supplier can force you to stop using the system until you comply.

It seems highly probable to me that unless your 3 kW load also has in parallel a very large capacitor, it will cause roughly 3 times the dip of the 1 kW loads, hence it will be that much more likely to create annoyance and attract the attention of the authorities.

I will say again- I'm not running it in the A/F mode because of flicker its actually because of the type of load.

I want the 1Kw loads either OFF or ON at full power and nothing in between. The 3Kw load is pure resistance and doesn't require any similar requirement. but a 3kw load in A/F would be on for 0.4166 seconds with very slightly more PV generated than base load and that's not allowing for any margin. And at the other end when the surplus PV available is just below the 3Kw load the triac would need to be off for only slightly more than the 0.4166 seconds before the energy bucket was full again so A/F would waste loads of energy to the grid unless the timings are removed.

I know exactly what flicker is and was on the receiving end of it many years ago in a small village that I lived In. It took the DNO months to find the faulty item and only then because they saw the same equipment in another village with the same problem, but that's another story.

To be perfectly honest I think Im just going to leave the forum. To be blunt I now have a system that works perfectly and you can just go on any work out the rest for yourselves.

That's a pity.   Thanks for acknowledging the help that I've given you.

Robin / Tinbum

Re. antiflicker not working so well with such a small energy bucket, very true, which is disappointing, but thankfully my loads that have to run antiflicker are only 1Kw each

I can confirm that changing the Energy Bucket size to 1250 joules ( I have an Actaris Ace1000 Consumption Electricity Meter) will now let me use the Anti Flicker Mode in the MK2i sketch

So i concur with Tinbum that the Actaris Ace1000 meter has a much smaller energy bucket than most other meters

the settings that I used in the sketch are:

#define JOULES_PER_WATT_HOUR 1250

float minTimeBetweenActivationsinAFmode = 1;   // <-- anti-flicker requirement (seconds)

float offsetOfEnergyThresholdsInAFmode = 0.22; // any value higher than 0.22 would cause the green LED (on the meter) to go out

regards

Mark

I have an Ampy Automation (now Landis & Gyr) Type 5196A consumption meter.

During periods when say > 1kW of surplus PV is available and my energy diverter is operating in low frequency anti flicker mode the red LED on my meter is permanantly lit.

If my meter is disconnected from all loads the LED is permanantly lit.

If the surplus PV is only ~ 100W and anti flicker diverting is operating the LED is lit most of the time but occasionally goes out but does not produce the familiar brief pulse that is normally identified as a charge pulse.

When the LED is off and a small reverse flow is occuring the LED remains OFF for several seconds before returning to the steady on state.

So, a few questions.

1. Is there a power threshold that must be exceeded before the meters internal counter begins to decrement?
2. If so, does this mean that when diverting small amounts of power we should take account of the threshold?
3. Could the previous posts regarding the Actaris have more to do with the level of power being diverted than the flicker rate?
4. Does the Ampy 5196A charge when the LED goes from ON to OFF or does it only charge on a pulse?

Brian D: During periods when say > 1kW of surplus PV is available and my energy diverter is operating in low frequency anti flicker mode the red LED on my meter is permanantly lit.

The reason that your meter's LED is lit is that surplus power is generally lost (i.e. donated to the grid) at startup.  This occurs at the start of each period when surplus power becomes available.  As the router's energy bucket climbs from 0% to 90%, so the meter's equivalent mechanism falls by a similar amount.  Unless the meter was on the verge of issuing its next consumption pulse, it will hit its lower endpoint and the familiar red LED will appear as some energy is irretrievably lost.

If we were to monitor and react to the meter's pulses, then the two systems could be maintained in a state of alignment while consumption occurs.  The start of each episode of surplus power would then be 'clean', with no loss of energy and no LED going on.  While diverting power, we would then have a positive indication of the meter's "sweet zone" being exceeded at either end of the usable range:  if the LED goes on, we've hit the lower limit; if there's a pulse, we've exceeded the upper limit. 

When using an A/F range of maybe 80% of the 1 Wh sweet zone that most meters provide, there's not much spare room to play with, hence the need for accurate calibration and good linearity.

If the surplus PV is only ~ 100W and anti flicker diverting is operating the LED is lit most of the time but occasionally goes out but does not produce the familiar brief pulse that is normally identified as a charge pulse.

If the LED ever goes from on->off, I am confident that you have been charged.  It may not look like a pulse, but it has the same effect as one.  I ran tests to demonstrate this back in October, as documented with my DigitalMeterEmulator tool.  There's a link to this at http://openenergymonitor.org/emon/node/1757 .

When the LED is off and a small reverse flow is occuring the LED remains OFF for several seconds before returning to the steady on state.

That's because the LED only goes on when the meter's internal 1 Wh monitor hits its lower limit.  Some nice diagrams about this have recently appeared at http://openenergymonitor.org/emon/buildingblocks/meters .

So, a few questions.

1. Is there a power threshold that must be exceeded before the meters internal counter begins to decrement?

No, it will decrement immediately.

2. If so, does this mean that when diverting small amounts of power we should take account of the threshold?

N/A

3. Could the previous posts regarding the Actaris have more to do with the level of power being diverted than the flicker rate?

No, it's just that some meters have less range that can be usefully exploited. 

4. Does the Ampy 5196A charge when the LED goes from ON to OFF or does it only charge on a pulse?

Yes, it does.

Thanks Robin that's an excellent reply.

I have more questions so if you will bear with me.

My problem is that although I can look at my energy diverter in action and convince myself that it works as intended when I try to prove the method of operation on paper I run into difficulty. The second link you provided has a nice image which I have modified slightly to help explain my problem and have attached to this post. I have added the blue line and the green line.

The original drawing shows the ideal situation where the energy fluctuations are oscillated through the meter at roughly the half way point of the 1Wh 'energy packet'. In his ideal situation I have no problem.

My diagram shows what I think will happen in the real world given that our energy controllers are not synchronised to the internal counter in the meter. Presumably the first time we cross the upper energy packet point and produce a charge pulse this will reset the internal counter and set the empty point. We now pour some energy into the meter but its counter is already zero and does not go negative so the energy is lost but the base line is now re-defined and when we consume energy < 1Wh there is no problem but when we replace it we are going right to the wire which means there is a good chance that we could cross the base line and therefore effectively store insufficient energy to cover our next extraction pulse.

So far?

I've yet to build a PV  router but just spotted this issue with an AMPY meter. My meter is an Ampy 5193A. Does anyone know if this model behaves like the similarly numbered model 5196A that Brian has?

Bob

When energy flows backwards through the meter beyond the point where it can be recovered without penalty, the meter and router are likely to slip relative to each other. 

Robert and I have had various discussions about the best way to show by means of a diagram what's going on.  One way of explaining the meter's behaviour is that the point where the next charge pulse will appear slips closer (it's always 3600 J above the point where non-recoverable export ceases, i.e. less than 3600 J after the previous one).  Another way is to regard the meter as simply 'losing' this non-recoverable energy so that the meter sits precisely at its 0 J point until consumption re-starts.  This latter approach is as depicted in the Building Blocks piece.

The lines you've drawn suggest that you're thinking along to similar lines to the first explanation.  Both are equivalent.  Until both systems are synchronised by using meter pulses (and on-off transitions), some energy is bound to be lost at the start of most periods of surplus power.  Especially when in A/F mode. 

But we're no doubt only talking pico pence!

9fingers

Let me know when you find out and if it is, I'll add that meter to the list of exceptions. Even though the meter constant is 1000 pulses per kWh, as we've seen the meter constant is not a reliable indication. The 5196 'packet' was 1 pulse/3.6, so maybe yours is 1000 J ?  I think we won't know until somebody checks one.

This is all I can find about it:

Operational Requirements
Measurement
The Meter is a 220 Vac - 240 Vac 50Hz 15/20 - 100 Amp Single Phase Credit Meter. It contains an independent measuring element allowing consumed energy to be measured. The meter measures and registers kWh to class 1.0. There is a red LED mounted on the front panel of the meter pulsing at a rate of 1 000 pulses per kWh for energy registration.
Total kWh Register
The total kWhs measured are stored internally to 3 decimal places. The total kWhs are displayed on the meter to a maximum of 2 decimal places unless programmed via the Flag Port (see User Interfaces) to 3 decimal places for testing purposes. The Total kWh register range is 00000.000 - 99999.999 kWh
Reverse Energy
Reverse Energy is detected if export energy greater than the meters starting threshold is measured. If reverse energy is detected the display alternates between a Reverse Energy Detected message and the default display.
Reverse Energy Register
The reverse kWhs consumed by the meter are stored internally to 3 decimal places but only displayed to a maximum of 2 decimal places. The Reverse kWh register range is 00000.000 - 99999.999 kWh
Meter Memory
All the meter's data is recorded in a Ferroelectric Random Access Memory (FRAM) under the control of the microprocessor. All the kWh registers are stored in the FRAM and are updated every 1/100 th of a kWh. The FRAM is guaranteed for a minimum of 10 000 000 000 write cycles.
Anticreep
Below starting current the meter enters into an anticreep mode. In this state the meter registration LED is permanently lit and the registers do not increment. The Led remains lit until the meter current is increased in either the forward or reverse direction beyond the starting current.
Temperature Range Limit
range of operation : -20 C to 55 C
Storage range* : -25 C to 70 C This complies with IEC 1036 : section 4.3.1.
* Maximum period of 6 hours at the extremes of this temperature range.
Power Supply Rated Voltage : 220 - 240 Vac (230 Vac Nominal)
Operating Voltage Range : +15% to -20%
Influence of Supply Voltage
The meter complies with IEC1036: Section 4.4.2.
Operation over the voltage range complies with IEC 1036: Section 4.4.2.1. with permissible error as given in IEC 1036 Table 14. For voltage dips and short interruptions the meter complies with IEC 1036: section 4.4.2.2 and is tested according to IEC 1036: Section 5.4.2.1.
Current Range: 15/20 to 100 Amps
Frequency: 50Hz
Power Burden: Less than 2
 

markcarter10:

So i concur with Tinbum that the Actaris Ace1000 meter has a much smaller energy bucket than most other meters
the settings that I used in the sketch are:
#define JOULES_PER_WATT_HOUR 1250

...

In my Mk2i_rev4 code, this definition is only used in one place, to define the energy bucket's capacity.  It may be helpful to change the name too, so as to avoid any confusion later.  How about:

#define ENERGY_BUCKET_SIZE_JOULES 1250

Brian D: So, a few questions.

1. Is there a power threshold that must be exceeded before the meters internal counter begins to decrement?

calypso_rae: No, it will decrement immediately.

Sorry, Brian, seems I was wrong on that one.  From the spec that Robert has just posted, it appears that meters don't register reverse current until the starting threshold has been exceeded.  However, while a router is actively diverting surplus power, energy flow is likely to be considerably above any starting threshold as the dump load cycles on and off.

Robin

In my Mk2i_rev4 code, this definition is only used in one place, to define the energy bucket's capacity.  It may be helpful to change the name too, so as to avoid any confusion later.  How about:

#define ENERGY_BUCKET_SIZE_JOULES 1250

Sounds reasonable and yes clearer

Mark

If the diagram that I posted above is correct then in that example energy diverting is not occurring in the middle of the meters 'sweet zone' but is running very close to the lower limit.

This could be improved by introducing a sensor to monitor the meter LED and synchronise on charge pulses.

Alternatively, when the software recognises that exporting has started again it should allow the first burst to exceed the energy packet capacity of the meter thereby ensuring the internal counters are zero and then extract slightly more than the standard amount to ensure that operation is once more in the middle of the 'sweet zone'.

A second diagram is attached showing the effect of what I am proposing.

Power diversion doesn't have to happen right in the centre of the meter's 'sweet zone'. 

One end of the zone is friendlier that the other.  The further away from the scorpion's end the better, IMHO!

it appears that meters don't register reverse current until the starting threshold has been exceeded. 

should read:

meters don't register ANY current until the starting threshold has been exceeded.

Though when you equate the starting current to power, they don't give much away! - maybe 1 CFL, and a little one at that.

Thanks for the spec details Robert.

I think some of the features are dependent on the programming by the installer.

For example my meter alternates between Red (reverse energy detected) and the imported total power. It never displays the exported power. Also the led stays on continuously during export.

I suspect that their statement "Below starting current the meter enters into an anticreep mode. In this state the meter registration LED is permanently lit and the registers do not increment. The Led remains lit until the meter current is increased in either the forward or reverse direction beyond the starting current."

will hold true if the meter were programmed to display export.

I've got a few other jobs on the go at the moment - specifying, ordering and starting the install of my Solar Thermal system - but the PV router is lurking in the background and I must assemble the hardware when I get an idle moment.

I'm guessing this will be the only way I can investigate the energy bucket size or is there another way given that I can't interfere with this meter.

Bob

I'm guessing this will be the only way I can investigate the energy bucket size or is there another way given that I can't interfere with this meter.

The way to quantify the "sweet zone" of a meter is to determine the maximum amount of energy that can flow in the reverse direction before the LED comes on.  This will occur when reverse flow starts just before the next consumption pulse is due.

The fact that the meter is permanently connected to the incoming supply mains does present a bit of a challenge, but it's not unsurmountable.  Here's how I would go about it:

1)  Construct some kind of measurement system with which can measure the flow of energy, and then calibrate this system using something that you can trust.  A 3kW kettle maybe.   With its built-in calibration routine, my Mk2i_rev4 PV Router sketch would be fine for this.  It can run on an Arduino on an emonTx, and just needs a pair of input sensors. 

1a)  Even better would be to rig up a sensor which can record each meter pulse.  The schematic and supporting code is already included in the above sketch.  You could then calibrate your system with ease by adjusting it to it record exactly 3600 Joules per meter pulse.

2)  Fit your calibrated system to your supply point, adjacent to the meter, and get it to display the energy level in your bucket repeatedly.  For this purpose, you could usefully use the variable  energyInBucket_4led_long  which has no upper or lower limits.

3) While surplus power is available, find a combination of loads such that there is only a small amount of residual export.  Then turn on a Big Load so that consumption resumes.

4) Just before the next consumption pulse is due, turn off the Big Load and note the bucket's level.  Then record the level when the meter's LED goes on.  The difference between these two readings is the "sweet zone" of your meter.

An approximate result could be obtained using a proprietary clip-on meter.  Just measure the amount of reverse current and the maximum time for which it can flow before the LED comes on.
 

Thanks Robin.

I saw a pretty similar meter on ebay today but the model number was different so I did not think it would help.

I'll try and get some hardware up & running asap and give your suggestions a try.

Bob

Hi All, built the MK2 october-ish last year, all I can say is thank you very much Robin for the diagrams and program data, and to all  the rest of you educated guys with your contributions in making this such a success. Anyhow  enough praise, I have just joined so yet another that's no longer "Lurking".
Up until a few days ago my unit was switching surplus energy to the cheap Argos convector. I have just finished installing a 175ltr presurised direct tank in the  loft. The challenge was to feed cold water mains to the presurised tank, this (weather dependent) being the primary hot water supply for the house. When the solar heated water has depleted the top thermostat closes and operates a 3 port valve that will then divert the mains pressure cold water to my combi boiler also in the loft. Once sufficient solar hot water is acheived in the pressurised vessel the top thermostat will open thereby causing the 3 port valve to divert cold water pressure back to the vessel.  The hot water output from the combi boiler and vessel are common. Just fine tuning the stats over the next couple of days, but early experience  shows it working as designed. Had a lovely shower this morning on yesterdays sunshine. Nice having free hot water. Thanks again Robin and team.  I have posted a couple of pics and video of the install if any one is interested at dickiewelham.dyndns.org:80/public/ .

I'm really interested in a  secondary output that I believe was mentioned earlier in the forum, the Idea being that when the bucket still indicates surplus with the first output  full on then the secondary would start switching the surplus i.e. 3kw PV generated energy could supply a 2kw load on the first full on output whilst switching the remaining 1kw to another load. Also when the Emersion stat opens all the suplus would be available on the Second output, hope this makes sense.  I have not got a clue on programming (Bob Hope/No Hope) so wondered what config I would need to add to the original sketch to fire a second output to a second MOC/Triac, Can anyone help?

Hi Dickie,  I'm delighted to hear that another Mk2 build is providing good service.  Wow, that's some heatsink!

Within the next few days, I'm intending to post a revised version of my Mk2i sketch which will support a remote load via an RF link.  If everything goes to plan, the priority of the remote load will be switchable.  When selected as the higher priority, a surplusPV-powered kettle would then temporarily divert power away from heating the DWH.   In my case, I'm intending that the DHW will generally be top priority, with the remote dump only becoming live when the tank is fully up to temperature.  Not sure yet what the remote capability will be used for, a small storage heater maybe, or just a simple heater for drying clothes over (if I can't be bothered to peg them outside!).

Thanks Robin, Looking forward to seeing how this will work, I'm doing extension work at the moment so I have run in a 2.5 mm cable for a Kitchen and Hall  PV Socket back to the Mk2 Box in my harry potter cupboard. This also houses the Meter and Consumer unit, so I will  able to mount the second Triac on the monster Heat Sink without the need for RF LOL! However really Interested to see the RF setup, great idea.

While developing the code to support a remote load via an RF link, I've stumbled across an anomaly which has been present right from Day 1 of the Mk2 code. 

There has always been a start-up period to allow the LP filter to settle.  This is the filter which allows voltage samples to be grouped into separate mains cycles.  Until this start-up period has expired, the energy bucket is not updated.  The power-routing logic, however, has always been operational right from the start.  With the benefit of hindsight, this makes little sense.  It would be far better for everything to be disabled until after the LPF has settled.

An easy way to fix this bug is to move the LPF logic into the negative half of the cycle which previously had nothing to do.  All of the processing which is specific to positive samples can then be disabled until the start-up period has expired.  The start-up period now needs to be defined using millis(), rather than cycleCount.

This fix will appear in Mk2i_rev5 in due course.  I've also updated Mk2_PV_Router_mini in the same way, as attached.

I've just started building the hardware for the PV router, mainly at this stage to investigate the energy bucket on my Ampy meter.

All going well so far and I've been testing the CT ratio- burden resistor and adjusting the voltage input to get the recommended 800 ish ADC steps using Robin's MinAndMaxValues sketch.

I've noticed that with no AC input for either current or voltage, the ADC uncertainty is about 6 to 8 counts.

I immediately suspected my half rail bias supply. I'd already decoupled the +ve input to the op amp buffer so tried some filtering on the output bias line which made no difference.

I have completely removed the problem (if indeed there was a problem) by fitting  2200pf capacitors from Ain1 and Ain2 to 0v

With no ac input, the ADC values equal the min and max values at 509 (ideal 512) for minutes at a time and the total excursion of values is unaffected as far as I can see.

The impedance of the 2200pF is quite high at 50Hz (1.5Mohms) but is clearly removing higher frequency components.

I don't know if others have noticed this ADC noise?

Bob

When you've got a working pair of voltage & current sensors, you could try running my Mk2i PV Router code, I suggest revision 4.  A 10-second "Tallymode" run will show you a signature of the energy content of individual mains cycles so you'll be able to see how much spread you're getting.  By monitoring a known rate of energy flow (aka power), you should immediately able to assess the calibration state of your system.  If it's reading 50% low, then just double your value of powerCal. 

The same sketch supports a 'surplus PV' LED, as does the rev_5 version that I posted today.  When there's no current flowing, that LED rattles merrily on and off because each cycle's energy content is either slightly above zero or slightly below.  But when I fire up a 60W bulb, the LED goes firmly on.  This tells me that the amount of dither/noise is not great.

My Mk2a PV Router code also supports Tallymode, but the results are not displayed in Watts so it's less user-friendly.

PS.  If anyone's not found the Mk2i thread, it's probably worth a look.  That version now supports multiple loads including a remote load via an RF link, and switchable priorities with anti-flicker.  And all running super fast on Jörg's interrupt-based core.

Should I be checking phasecal before taking the TALLYMODE checks?

TIA

Bob

When measuring real power, phasecal makes so little difference I just leave it at 1.0 and forget about it.  

There's a video showing how insensitive this setting is at   http://www.youtube.com/watch?v=v8ifoUJvcXY 

Thanks Robin.

Good progress today. I progressed through Phasecal, (where i agree it makes little difference) to Tallymode and then onto my test rig with a variac to represent the Solar input and dumping into a 2kW convector. I had the workshop floo-tubes flickering nicely and then flipped into Antiflicker mode and they stopped flicking. Brilliant

Superb documentation made everything very easy - excellent job!

I now need to tidy up my hardware before moving into the garage and to try and characterise my import meter over the next few days.

Bob

I think I now have some reliable results of the size of the energy bucket in the AMPY 5193A (year 2000 vintage)

I used the method suggested by Robin earlier which i've repeated below in italics

The way to quantify the "sweet zone" of a meter is to determine the maximum amount of energy that can flow in the reverse direction before the LED comes on.  This will occur when reverse flow starts just before the next consumption pulse is due.

The fact that the meter is permanently connected to the incoming supply mains does present a bit of a challenge, but it's not unsurmountable.  Here's how I would go about it:

1)  Construct some kind of measurement system with which can measure the flow of energy, and then calibrate this system using something that you can trust.  A 3kW kettle maybe.   With its built-in calibration routine, my Mk2i_rev4 PV Router sketch would be fine for this.  It can run on an Arduino on an emonTx, and just needs a pair of input sensors. 

1a)  Even better would be to rig up a sensor which can record each meter pulse.  The schematic and supporting code is already included in the above sketch.  You could then calibrate your system with ease by adjusting it to it record exactly 3600 Joules per meter pulse.

2)  Fit your calibrated system to your supply point, adjacent to the meter, and get it to display the energy level in your bucket repeatedly.  For this purpose, you could usefully use the variable  energyInBucket_4led_long  which has no upper or lower limits.

3) While surplus power is available, find a combination of loads such that there is only a small amount of residual export.  Then turn on a Big Load so that consumption resumes.

4) Just before the next consumption pulse is due, turn off the Big Load and note the bucket's level.  Then record the level when the meter's LED goes on.  The difference between these two readings is the "sweet zone" of your meter.

I've a test rig that incorporates a Landis & Gyr E110 type 5235B year 2011 .

I have a variable transformer injecting current as the 'solar PV' source and a 2kW convector as the load.

I've added a little code to ver4 that prints out every 10th value of energyInBucket_4led_long - simply to make it easier to read.

My calibration factor is 0.044 which makes a 3600J bucket equal to 4090909 internally.

Running Robin's method on my 5235B meter I got an average bucket size of 4000000 which is very close to 4090909 suggesting that my test meter does indeed have a 3600J bucket.

Switching to my house meter Ampy 5193A , I took about 20 readings. These proved more difficult to do with domestic loads switching on and off. I turned off everything I could think of.

Having rejected the less credible results, I was left with 10 reasonable ones which averaged to 3.36 x10^6

Calculation suggests  the Ampy meter has a bucket of 2956J       (3600 x 3.36 x10^6/4.090909 x10^6)

This is probably 3000J in practise

This is not much difference to the common bucket size of 3600J and looking at the internal thresholds in Robin's code,

the upper and lower bucket  thresholds are set to 60% and 30% of the bucket volume.

My conclusion is that I will proceed with my installation using the standard bucket size for now but will keep an eye on performance and if needed try modifying the bucket to 3000J.

Thanks to Robin for suggesting the method.

Bob

Having calibrated your system using Mk2i_rev4, it may be easier to work with a version of the code where everything is done using FP maths.  Mk2_PV_Router_mini_2, which conveniently displays the results of its 'no-limits' bucket every second, might be a good choice. 

Regardless of the underlying maths format, all Mk2 versions should give similar results.  If they don't, please send me a PM!

Teething Problems

Hi all, brand new to this so please treat me gently :)

I have built a router with Rich's PCB's and an Ardunio Leaonardo.

All wired up and tested out (continuity) across all soldered joints but i just cant get the router to function properly!

I should add that i know nothing about sketches but i am keen to learn but i think that it may be something hardware related that is stopping the router from working

all of the following completed in the hours of darkness!

I originally uploaded Rev 4 but with no avail (no output at all) - so i decided to revert to Rev 2 and bingo, output at full whack (i have a low res clamp-meter so could monitor the output on the immersion conductor) thinking that all i need to do now is swap the CT clamp orientation that is what i did, sadly at that point the output was still running at full whack when i would have expected it to drop off?

I am using the SCT 013 000 CT and when clamped around a conductor using 9A i get 3V straight from the CT "tails" - this translates into 0.275v after the 150 ohm burden resistor on the board

I was recommended to try the "Min and maxvalues" sketch, which i did but got the following 

1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
629     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
0     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023
1023     0  1023

However hard i try i don't really understand what these figures represent so don't know if they are good or bad (but i suspect bad)

Any assistance greatly received and thank you in advance :)

Those values are indeed bad - big time!

If you look at the sketch, around line 16, the output you see is a result of the "Serial.print(.....)" statements.

  Serial.print(val);  Serial.print("     ");
  Serial.print(minVal); Serial.print("  ");
  Serial.println(maxVal);

Making a few intelligent guesses (often necessary with programming!) you can deduce that the first number is the value read on that excursion around the loop, the next is the minimum value and the last the maximum value since the sketch started.

You have a serious problem with your analogue input. It is flipping between 0 and 1023 (full scale) with only one value somewhere in between. The input voltage is swinging far too much. 

Which input are you looking at? At line 9 in the sketch, it says (as downloaded) you are reading the voltage input - if you've built it according to Robin's diagram. That means you have some wrong resistors between your ac-ac adapter or transformer and the analogue input. Are the 150 k and 15 k in the correct positions? - my best guess is they are swapped around. The voltage at the analogue input should be not more than about 1.5 v a.c. and it should 'sit' at 2.5 V d.c - half way between ground and the 5 V supply.

So the minmax sketch should report the min around 100 and the max around 900 - give or take depending on your mains voltage for the voltage input.

Yes, as Robert says, there appears to be a serious problem with your input sensors. They need to be generating suitably sized sine waves, otherwise nothing else will be work as intended.

Sample output files were posted along with my minAndMaxValues and RawSamplesTool sketches.  You need to get your rig to do likewise.

If you spend a bit of time looking at these sketches, I'm sure you should be able to see what's going on. 

Hi Both, thank you for your time and assistance

Ok, so i cant read - or at least tell the difference between a 150K and a 150 ohm resistor (Doh)

These are now swapped around and i have an output of around 1v on AN2 input and 2.5v on AN1 as you have said that I should - so I'm making progress (debatable I know)

Robin, I've looked for the sample outputs but cant find them i am afraid would you be so kind as to post the link?

Currently (no pun intented) I am seeing

AN1 - CT - min = 385 and max = 641

AN2 - V - min 211 and max 803

Look at that I managed to change the monitored pin (ok but i think that is making progress :))

So following that i confidentially uploaded Rev2 of the router sketch and the Triac doesn't come on permanently as it did before, but now it isn't coming on at all, even if I swap the CT orientation around

Any ideas what i should look at next please?

cheers

Griff

The index to all of Robin's work is http://openenergymonitor.org/emon/node/1757 There's a picture in the RawSamplesTool post.

The current you read (385 - 641) was with 9 A load? That's exactly a quarter of full scale (coincidentally).

OK, it looks as if you have workable values for the inputs, you've proved the triac can come on so the output is OK, so it looks as if the hardware side is probably working.

Just to be clear, you are using Mk2a_PV_Router_rev2.ino? Have you read all the comments at the beginning of the sketch and set powerCal and voltageCal?

Hi Robert

Yes I've read the introduction and calibration section and deduced that as my range is around 600 + 100 either way = 800 so the default looks OK for Voltage Cal and I've left the other two at default

The result is listed below and is the result of the sample from "raw samples" - so I think all should be OK, although theres room for improvement 

I'm attempting (on Robins suggestion) to use Mk2i - Rev 2 to start with but im not precious if you think there is a different version that may be more suitable to start with?

Many thanks

Griff

with CT in different orientation and a load of 3.4A

And with a 16.4A load the data in the attached PDF is shown

Does this mean i need to recal my CT for lower Current measurements?

cheers

I've got a pretty good idea how Robin's software and hardware works, but clearly my knowledge is not as detailed as his. Those waveforms look OK to me, but is it still not working? I presume you have carefully checked the mains wiring.

Have you got a LED and a series resistor on pin 13 of the Arduino output - and does the LED flash?  That pin is driven at the same time as the triac trigger.

I don't know off the top of my head the phase relationship the controller expects, so unless that is the problem (simply cured by reversing the c.t.), then we'll have to wait for Robin to help.

Hi, what exactly is the problem?  Those waveforms look reasonable to me. 

I'm intrigued by the peak in the current waveform at the mid-point of each mains half-cycle, when the voltage tends to droop.  This seems to be the behaviour of most PV inverters, but I presume you weren't measuring your inverter's output at the time.

I you think everything's set up OK, why not try a Tallymode run with, say, Mk2i_rev4.  This should show you exactly what's going on.  Start with no currents anywhere, and you should get a small distribution of energy values around the 0W point. 

Then measure a small load around 100W, and your tally values should reflect this.  Simulated PV needs to return +ve power values which will make the levcel in the energy bucket increase.  Then, when it reaches 1800J (in normal mode), the triac should turn on and cause your dump load to draw power.  This will be seen as a small peak in the -ve part of your tallies, assuming that you've set the end values appropriately.

Rather than take up lots of thread space, results files can be attached to forum postings very easily.  Paste the contents of the Serial Monitor window to a .txt file (using Notepad or similar), then attach it to your post using the "File Attachments" link just below the window that you type in.  Having attached the file, you then need to 'tick' the "List" box.  If you forget to do this, the file won't be visible to others.  No problem we've all done it.  Just "edit" the message, and tick the box.

richmc has pointed out that you appear to be using the Arduino Leonardo rather than the Uno. I have no knowledge of those units, but if that is indeed the case, have you checked that you are using the correct output pin to drive the opto-trigger? (If you change the hardware to something different, you always need to check compatibility - and adapt the design, hardware or software or both, accordingly).

Hi Robert et all

FYI - i have tidied up my posts, apologies for getting carried away with those!

I have checked in so far as i can that leonardo pins are the same via the Ardunio site 

I have now loaded up Mk2i_rev4 and still no success, but now strugling to run the Tallymode - i think due to the difference in the way in which it handles serial statements - 

im going to now post on the relevant string and thank you in advance for any further assistance that you can give me

cheers

The thing that's different about Tallymode is that the user is required to supply some informatiuon during the setup phase.   If the serial display doesn't work right from the word go, that can be a problem.

The first question is "For how many seconds should the test run?"  So if you just type in, say, '3' '0' 'c/r' (for 30 seconds), you can then continue with the rest of the sequence.  This problem does not occur with an Arduino Uno, but does seem to do so when programming an emonTx via the necessary USB-to-UART adapter + cable.

This topic has now moved to the Mk2i PV Router thread ...

The Sunnyboy regulates PV out put to prevent overcharging when the minigrid frequency is at 51hz. Between 50 and 51 is safe in terms of battery over charging. Its just an indicator that the energy in the system is close to being too much to match active loads or battery charging operations. This gives a margin within which a set point could be specified.

I imagine it working something like this. If a frequency greater than 50.5hz is detected , load is added via the triac until the frequency drops to 50.5.  If the frequency drops below 50.5 triac load is reduced until the target frequency is reached.  That logic seems simple to me.  The Sunny Island has done all the hardwork, just need something that can respond to the frequency shift to add or reduce loads to reach the set point of 50.5hz..... Does anyone know of any workshops or events where this stuff could be covered?

I apperciate the suggestions from others about relays controlled by the Sunnyboy or Sunny Island but they are too simplistic for this setup where the amount of power consumed by battery charging is dynamic due to IUoU charge pattern. The SB has a self consumption relay which can be triggered above specified power output, but that output is only reached if there is enough load to allow high production, which wont occour when the the system is throttling down...which is when I want to use the excess!

Robins triac controlled load, balanced by PID seems ideal.

For example: If there was constant 2kw of PV available for 5 hours. No load on the house and the SI had just started a bulk charge phase, all 2kw would be utilised in charging initially, but as the batteries filled, the amount of current required drops off. The SI will increase the grid fequency incrementally to reduce the SB output until the battery is full at which point the minigrid fequency will be 52hz and the PV output 0.  With a triac, load can be added incrementally thoughout the charge process to make use of the excess without interfering with the charge cycle. this is a simplified scenario, obviouly it could handle any situation.  All it has to do is maintain 50.5hz

I think I must stop obsessing about this as its beyond my capability.  But again if anyone comes across any resources or mature projects that are trying to accomplish the same thing let me know.  Thanks

Will

Are you off-grid? I assume so as the UK grid tolerance is ±1%. You might want to look at MartinR's PLL controller (derived from the Mk2). This locks to, and consequently measures, the frequency so that information would be available to your control algorithm.

Yeah, Its an offgrid setup which is why the the Sunny Island is allowed to use Frequency Shift Power Control to regulate SunnBoys on the minigrid. Its pretty smart, if its a sunny day and the system spends hours fully regulating by holding the frequency at 52 hz it will drop the frequency to 48 hz for the same period over night to correct any mains frequency dependent devices such as clocks.  Although we dont have anything like that,  I like the fact that SMA thought of it! Im chuffed to bits with it. Ive already saved about £1700 in diesel costs and made £1000 in generation payments. (Its the MCS scheme but technically not a Feed In Tarrif payment as Im not on the grid.) Thanks for the link to the PLL library.  Honestly, at present, its beyond me.  Im hoping I can spark the interest of someone with more brains than me :o)

To check that the output stage of a PV Router is working correctly, there's no need for the rest of the system to be present.  With a series resistor to limit the current to around 15 mA, the opto-isolator can be activated using nothing more than a 9V battery.

A video showing this technique will soon be available at: http://youtu.be/hpClB_5mjRc

At last after several months out doing unimportant things like earning a crust and falling down stairs I`ve got my 3 phase Mk2 working. Nothing fancy (none of these interrupt based thingies or anti flicker- just the old fashioned steam power Mk2). Using Rich`s boards I`m now diverting about 9kw using one Mk2 per phase. Glad to say it worked first time. I put in 3 disc meters (at just a few quid each, cheapest way of monitoring size and direction of current) and its good to see them judder to a halt as soon as you flip the switch.

Just in time for summer!

(mind you my workshop doesnt heat up until about August, and last year not even then)

Depending on your exact setup noah, 3 separate systems might not be the best solution. 3-phase meters have a single "energy bucket" so ideally you want to implement the same thing for diversion. That way you can you can pass PV energy between phases if necessary.

Martin

I havnt followed (or been able to follow) all the possibilities associated with this topic but certainly being able to somehow offset overuse on one phase with underuse on another would be handy. Is this in fact possible and if so how complex is it to achieve ?

With a Mk2-type router, the input and output sides are functionally separate.  They are only linked by the energy bucket.  You have three such systems at present, one on each phase, all acting independently.

One approach might be to leave the measurement parts of your three existing systems just as they are, but to add an extra control system which would deal with the distribution of surplus power.  Each of the three monitor systems would routinely convey the state of its energy bucket to the controller.   The controller could then turn on each of the dump-loads as necessary in order to balance the entire system.

A simple way to communicate between these systems could be for each of the monitor systems to continuously output the state of its energy bucket by means of a pseudo-analog signal via (smoothed) PWM.  The controller could then routinely poll these signals.  By this means there would be no complex comms protocols to worry about.

I have it working on my 3-phase system noah, so it's certainly possible. Since the stacked emonTxs are linked via the I2C bus I can pass the PV energy accumulated during each cycle from the slaves to the master. There is a single energy bucket on the master which sums the energy from all 3 sources. Each emonTx has 2 dump loads controlled via signals from the master.

It should be possible to link Uno boards in the same way using wires.

One complication of having 3 phases is that you have to scale the energy for each phase before adding it to the total as the calibration will be different for each phase.

If any of you clever gents wants to design something then I`m all for it. I wouldnt know even where to start. I`d certainly be eternally grateful.

If you were starting from scratch I'd suggest using emonTxs and cloning my system, but if you are not comfortable with coding then adapting it to work with your hardware will probably be a step too far. It would be difficult for Robin to develop anything either without access to a 3-phase supply.

One problem with the arrangement you have is that you could be charged for power that you think is coming from your generation system (water wheel in your case?) if you are not careful. Imagine a situation where you have 1kW of generation on each of the 3 phases and a 3kW load on phase 1. Your meter will see this as no overall generation or consumption. However, your Mk2s on phases 2 and 3 will each see 1kW of surplus energy and divert this to your dump loads and the meter will see 2kW of import, for which you will be charged.

I've been having the odd thought about this problem and that possible situation had occurred to me too. I don't see any problem with having a single energy bucket which accepts the combined contributions of the three phases and I think that's a prerequisite, where I have the problem is deciding how best to share out the dump load when it's needed. From Noah's point of view, I think it would be preferable for his generator(s) to loaded as evenly as possible across the 3 phases, and to allow the grid to take up any unbalance. I think that implies that the algorithm needs share the dump load so that that is achieved. What I've no idea about is whether firing the three triacs the same amount of time (either in parallel or maybe in sequence) would be enough to be reasonably certain that this would happen - it depends on the generator fault level in relation to the supply fault level amongst many other things. And it gets even more interesting when one phase (or two) of dump load becomes unavailable.

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.

Two closing points for today:

1.  I agree with Robert and Martin that there should only be one energy bucket.  As the level in this bucket rises, the state of your dump load(s) should be varied so as to maintain the level within the zone that is permitted by your meter.   From a financial point of view I don't think it matters which phases your loads are connected to.  If you wanted to balance your overall loads across the three phases, which would seem a nice idea, the power distribution algorithm would become a whole lot more complicated.

2.  My previous idea about using PWM to indicate the state of three separate energy buckets is rubbish.  Sorry about that!

I was thinking about heating and the effects of unbalanced torques on the generators, and side effects on the generator's AVR, when I said I thought the generator would prefer to see a balanced load. Another thought has occurred to me: with a pulsating load, it would be wise to check for mechanical resonances particularly in the shaft (and coupling?) between the generator and the turbine, and it might be necessary to tweak the algorithm to avoid that. It might not happen, but if it did and was serious enough to provoke a failure it would be expensive.

I'm assuming noah's turbine is connected to the Grid so the only pulsating will be at the level of the flicker we see with PV systems - ie small. The impedance of the dump load will presumably be much greater than the impedance of the Grid.

For my floor heating I cycle through the loads on each phase in turn which reduces the flicker frequency on each phase by a factor of 3 - I hope!

When you posted you original 'stacked' design, Martin, I didn't understand how the three emonTx layers communicated between each other.  Looking at the Atmel datasheet, I see there is a serial comms mechanism that allows data interchance between connected processors.  The relevant pins on the 386 chip appear to be 27 and 28, also used for Analog inputs 4 and 5.

If Noah were to link these pins of his three Arduinos together, then the energy states of each monitor could be combined, much as your software does.  This hardware would then be functionally identical to your triple emonTx unit, albeit not as compact. 

One of the existing Arduinos could be designated as the master, and look after the top-level decisions.   Or a fourth processor could presumably be added which would means that the three monitor boards would remain identical.

With your existing system, how often do the slaves send energy data to the master?

Is there any reason why a mega 2560 couldn't be used as that has many more imputs, would be simpler and cost less than 3 separate boards?

You still have to do all the readings and all the processing, so the fidelity of the waveform capture would be compromised.

Yes the scenario with 3*1kw generated and 1*3 kw utilised is actually common as loads are not balanced. This is what I was expecting.

 System is grid connected so generator will always run pretty smoothly. So extra loading or subtracting from any phase should not lead to  mechanical problems.

I cant quite get my head around whether the energy bucket/s actually exist or are they almost purely conceptual?

The system as set up seems to do what it says on the tin: ie as if there are 3 energy buckets, all independent of each other. I can see that it will still work if there is only 1 but wouldn`t there be a lot of `overfilling` with each phase thinking it has a certain number of joules to play with and in fact only having a third of that amount?

What does it say on the tin: "donations to the electricity company"? :)

Do you not see that in the 3*1kW generated and 1*3 kW utilised situation the 2 unloaded phases will each divert 1kW to your dump loads so the total utilised will be 5kW when you are only generating 3kW?

So what exactly is an "energy bucket"?  Deep breath ...

The Mk2's energy bucket is simply a means of recording the net flow of real energy at the supply point.  A single-phase utility meter works in exactly the same way.  It monitors the flow of real energy, and updates its accumulator accordingly.  When a certain amount of energy has been imported, a charge-pulse is applied.  This causes a register within the meter to be incremented, and the accumulator is reset.  Between each charge-pulse, the accumulator winds its way up (or down) within a window which has a fixed range.  This window is the meter's "sweet zone" which typically spans 1 WattHour's worth of energy flow.

Because the router's window (aka energy bucket) is of the same range as the meter's window (aka sweet zone), the router can constrain the net flow of energy to remain within the meter's sweet zone thereby preventing any charge pulses.

As I understand it, a 3-phase system works in a very similar way.  Although the energy flow on each phase is measured separately, it is only the net flow which is monitored by the meter.  The Router should therefore aim to do likewise, which means that there should only be one energy bucket, as such.  This will be used to determine when the overall dumpload need to be increased or decreased.

Via the 2-wire interface by which adjacent processors can be linked, each of the three per-phase monitors can routinely send  energy flow contributions to the controller.  To keep track of this data in between such transmissions, each monitor would need to have its own accumulator.  This would not be a "bucket" as such, with min and max limits, but simply an endless (signed) accumulator which can be reset to zero after its content has been disclosed.

Every so often, the controller would request energy flow data for each of the individual phases.  Having updated the single energy bucket which records the overall flow, a decision would be taken as to whether the total amount of dumpload needs to be increased of decreased. 

For a fully balanced system, I think each dump-load should be capable of being driven by each phase.  Whenever a given load needs to be brought on, a decision would be taken as to which phase it should be driven by.  While that load needs to remains on, no other triac must attempt to drive it.  Having eventually been turned off, when that same load next needs to come again , a new decision would be taken as to which phase it should be driven by.  That decision would be based on recent energy contribution data from each of the individual per-phase monitors.

Hot-switching loads between phases, purely to maintain the per-phase balance, would surely be a non-starter.  If nothing else, there would need to be some guard zone when both triacs were off, which would result in "flicker".

Yes Martin, I thought that was exactly what I said. Its also what I expected from the setup so I`m not disappointed but obviously I`d like a setup which uses as little import as possible, however this is achieved.

Hi, i am from Spain and i have a Zerbox (same like MK2)

I need to avoid to export current because it is forvidden in Spain.

I have changed  safetyMargin_watts  with negatives values like -15, -35- -50- 70, but i always export current.

I have 400w of Solarpanels and 250w of minimum consumption. Actually i have a 2000w radiator heater, and i'l put a 1500w of water heater in a few days.

In afew months I would like to expand the solarpanels up  to 1500w.

In Spain the current is 230v, and i have 232-236v.

Someone would be kind enough to help to adjust the parameters of the program ?

a lot of thanks !!! and Congratulations for this Forum !

If you must never export energy, you must always be able to consume more than you generate. The Mk 2 controller will always try to balance consumption against generation so that zero energy is exported or imported. It will only be possible to do this when the load - lights, refrigerator, computer plus the controlled load of water heater and radiator heater - is equal to or greater than the power your Solar panels generate.

Have you read Diverting surplus PV Power?  Is your controller working at all - does the water heater switch on when there is generation? Are you measuring current at the correct place?  http://openenergymonitor.org/emon/sites/default/files/mk2typical.png  Is your c.t. the correct way round?  Which version of the software sketch are you using?  Have you tried to calibrate Voltage and Power - these are the main things you need to adjust.

Have you tried the tools here: http://openenergymonitor.org/emon/node/1757 and do you get reasonable numbers for example from http://openenergymonitor.org/emon/sites/default/files/rawSamplesTool.ino...

I need to check, but I think safetyMargin was found to be unnecessary - for the UK - and has been removed.

After nearly 12 months of fault-free operation, my original Mk2 breadboard rig has been officially retired in favour of a more respectable looking boxed up version.  This uses a pair of Rich's PCBs with a pcb-mounting transformer for the AC voltage source.  The original BTA41 triac and home-made heat-sink have been retained, mainly to see how long they keep going for.

I'm using a Magnelab CT rather than the standard YHDC one.  With its larger aperture, this CT allows a couple of extra coils to be tucked alongside the incoming Neutral line.  By this means, the rig's operation can be checked at any time, even when the PV system is not active.

Not bad for a beginner ;-)

You forgot to put an LED on the front!

Looks tidy Robin.

Robin,

Where do you get your plastic boxes from please? I'm using something externally similar but the internal mounting strips are in a diagonal X format. Yours at right angles look much easier to use.

You can just see the X here http://www.ebay.co.uk/itm/Sealed-Plastic-Enclosure-194-5x145x78mm-Electr...

They are well priced, reasonably sealed and machine well just difficult to use the internal mounts.

TIA

Bob

On the grounds that there's a prominent neon indicator just above, Rich, I decided to economise on the LED :D

Yes, Bob, that box was a dream to mount components in when I first assembled the rig before Easter.  The box itself has been kicking around here unused for maybe 20 years, but I've no idea where it came from.  The plastic is quite supple, and it takes mounting screws very easily.  Modern boxes seem to be more brittle.

The triac has finally got its mica washer and insulated mounting.  I've not fitted an RF unit because our secondary dump-load (a storage heater) did not appear to be effective.  It takes more power to cook up a storage heater than we are ever likely to have available.  A longer immersion heater element is the next obvious upgrade for our system.

I replaced the "normal/AF" metal switch by a plastic one so that the only exposed metal part is the heat-sink which is earthed.  The USB connector of the Uno unfortunately sticks out a little.  If mounting the same components again, I would fit the Uno slightly further inside the box so as to avoid this unnecessary protrusion.

Bob, the box you have is the one I use, I've found short self tappers are the best way of mounting stuff internally, but I do have to "dremel" away some of the plastic under the Arduino for it to sit flat. I find this box reasonably easy to work, not at all brittle as Robin says many are.

Robin you don't need the mica washer just a smear of conductive paste, belt and braces seems to apply.

Through the winter I used a cheap 2KW convection heater (£20 from Argos) that has 3 switched levels and sits in my hallway so helps supplement the heating in the hallway and up the stairs to the bedrooms.

I set the USB socket 5 or 6 mm back into the case, ideally there should be some type of grommet or cover for it.

Given the flexibility of the mounting channels, I could no doubt move the Uno a bit further into the box to prevent its USB socket from overhanging. 

I've always used conductive paste to get a good thermal contact, but as Robert has often pointed out, this doesn't isolate the triac electrically from the heatsink,   Hence my use of an insulated mounting kit from Spiratronics, or eqivalent, with some thermal paste for good measure.

With the heatsink also being earthed, this precaution is indeed belt & braces, but this is surely no bad thing when mains power is involved.  There is no fuse as such in the system, so if the immersion element were to fail, the triac could start to break down and who knows what may happen during its final moments.

For what it's worth, I prefer the Silicone Rubber Mounting Kits. These are allegedly better, at approx. 0.45°/W, and a lot less messy than conductive paste. And as Robin infers, you then need 2 faults to trip the breaker and 3 faults before it gets dangerous (insulation failure in the triac, in the mounting and finally a broken earth to the metalwork).

It would be interesting to try out various ways of mounting a triac: with silcone or mica washers, and dry or with thermal compound, to see how they behave.   If they're all passing the same current, the power that each one dissipates should be pretty much the same. 

Any takers? ...

If you earth the heatsink properly then no fault will be dangerous if the trip is working properly, and the only problem with paste is people use too much of it, if you use a mica washer you also have two lots of paste hence twice the opportunity to use too much . Silicon pads are initially better but as the heat dries thermal paste (if used properly) it becomes more effective. Never mount a device dry as it will seriously inhibit the ability to conduct heat. It's not so much what the device dissipates but the transfer to the heat sink that is impaired or improved.

A bigger potential problem is the wiring and connectors. I was sure that I fully tightened the connectors in my unit but the attached photos suggest differently.

The result was a Live to case short which tripped the house RCD

You didn't tin those wires first, did you? I was taught never to tin a stranded conductor. I was told that copper on its own has enough spring and maintains contact pressure; but solder, being soft, flows under pressure and eventually there is not enough pressure to assure a low resistance, resulting in heating.

Robert said:

You didn't tin those wires first, did you?

I did indeed tin them first! Your advice is appreciated and I shall not do that again.

On the diverter I changed the connector block for a larger size and beefed up the wiring plus I used longer tails to ensure that each is engaged by two screws. Finally I made sure the screws are damn tight but yes I tinned the wires again.

I will have another look soon.

Thanks

Brian

FWIW, I often 'tin' stranded wires too.  I've been told that this operation is not recommended because it reduces the ability of the wire to flex (which is fairly obvious) but that it's probably not a problem if no movement of the wiring is likely. 

I also like to double-back the ends of single wires that go into connector blocks; this seems to prevent the wire escaping around the side of the screw. 

When using screw terminals, twist the wire then double it back, the main object is to stop single strand whiskers escaping. A better plan is to crimp on a thin brass ferrule, you may have seen them in pre wired plugs.

You should only tin a wire that's going to be soldered to something else. 

Some information, some possibly useful and some not quite so:

Those ferrules are often called "bootlace ferrules" at least by RS and Spiratronics but not by Maplin (and they're tin plated copper, not brass, that's much too hard), and I must add the obligatory other suppliers for these exist!

In the good old days when appliances didn't come with fitted plugs, they often came with tinned ends to the flex - so loose connections in the plug were common. And the reason for tinning the wires? - solely to make it easier to handle during assembly and test. The little known advice then was cut the tinned ends off when fitting the plug.

Thin brass in my day Robert, that was MOD spec!  With real men doing the crimping (and some very tough women).

Second load on Robins MK2 diverter.

Using Honeywell strap on cylinder stat,I have been able to add a second load to Robins MK2 diverter.
With the cold weather we are having now,the boiler system gives us all the hot water we need.So when the sun shines,our solar system has no where to go.

With this in mind I came up with the idea of using the Honeywell strap on cylinder stat.to switch over to a convection heater.
The thermostat is just a temperature controlled single pole double throw switch.

Connecting pin 9 of arduino to the common contact marked C on the Stat,one can switch between the existing circuit ie Robins circuit and another external SSR based system.
The 5v supply in this case is common to all .

One can also use a rotary switch to select more devices.This is a manual system and one must remember to switch back to solar when the sun shines.

With the stat serving as auto switch,when the immersion heater stat switches off, the strap on stat which is strapped between the hot part of the cylinder and the cold part
would have reached the set temperature and switch over to contact 2.

In this state arduino pin 9 is now connected to contact 2. This in turn fires up the second ssr to drive a convection heater or another water tank.

(Please note that FAN HEATERS are not suitable due to inductive part of the fan.If the fan can be switched off it will be ok)

The good thing about this system is that if the temperature drops in the first cylinder,the strap on stat will switch over to contact 1.allowing immersion heater to start heating again.

I have been trying it out for over a week heating my living room when the sun shines.

Please see attached pics and diagram.

BTA41 blows!

Came down to workshop this morning and no heating.

I have 4 of R Mk2 and on one (on one 3.5kw leg of 3 phase turbine) had no output. MCB off- switched back on, plugged in resistance load and got an actual flame from BTA41.

I blew one of these before (by shorting out lead) and replaced it, has been working fine since.

This is the first to blow under its own steam so to speak. Perhaps the heating load (2 oil filled rads) are a bit close to the unit ( afew feet away and on most of the time) whereas the others are all in cold places.

Anyone else had a problem with these?

Hi Noah, you most be one of the very few UK users whose Mk2 systems are actually doing anything useful at present.  Yesterday there was a bit of sun, but recent days have been grim indeed on the generation front.  My total for Monday was 0.07 kWh, and the surplus power for that day was nil. 

No, I've never managed to blow up a triac.  Shivvering here in a chilly house (unless I fire up the gas boiler), I could really do with some turbines like yours in the back garden!

And there have been people berating me for recommending a 40 A device!

You seem to indicate that you think it may have overheated. What is the maximum current it was handling?  Other things to look at would be the efficiency of the heat sink - have you deburred the mounting face and is the triac making good contact, have you used heat sink compound or anything else to assure good thermal contact? 

Do you have a snubber fitted?

Robert

I think its probably the ambient temp being too high-someone could easily have pushed one of the heaters right next to the MK2 box and whacked up ambient to over 40. The other two on the turbine have same heatsinks  but are in cooler places. These three handle a max of 3.6kw each. There is good contact with heatsink.

My first MK2 is a fair bit older than these 3 and has been handling 3kw pretty consistently without a problem- mind you this is in a bigger housing and in an unheated area.

I`ll replace the triac and make sure the heaters are kept well away.

Turbine and waterwheel putting out just under 15kw. Dontcha love the rain?

You're talking then about 15 A (assuming 240 V). Let's say 16 A worst case. From the graph in the data sheet that means that the triac is dissipating fractionally less than 15W.  The maximum junction temperature is 125 °C and the resistance junction to case is 0.9 °C/W. That means the maximum case temperature is 125 - 15 * 0.9 = 111.5 °C.

I use silicone rubber mounting kits and their thermal resistance is 0.45 °C/W, that makes the heatsink temperature directly under the triac 111.5 - 15 * 0.45 = 104.75 °C.

If you have a 40 °C ambient, that means your heatsink needs to be at least (104.75 - 40) / 15 = 4.32 °C/W

If you have a temperature range and a thermocouple with your multimeter, you could try a drop of oil on the triac tab, put the thermocouple in the oil to give you good thermal contact and measure the temperature. Also, knowing the dissipation, if you know the thermal resistance of your heatsink and the mounting method, you can redo the sum above with your numbers and work out the maximum ambient temperature. If that's above the actual ambient, you're OK. If not, you need a better heatsink.

Robin claims his heatsinks are 1.5 °C/W, so they should be good to a ridiculous temperature - over 80 °C.

I am a "newbee" and I want to thank you, Robin, and your fellow enthusiasts for all the work on the Solar diverter.  I basically had zero knowledge of  electronics, soldering etc. and my programming goes back to FORTRAN IV in the early 70's. In spite of this, I was thrilled when I managed to build and install a working Mk 2 system using Robin's July 2012 circuit diagram and the August 2012 Arduino sketch.  On Sunday 8 December 2012  I harvested 17 kWhr of heat from 42 kWhr generated (only "losing" 2 units to the grid measured by an Iskra import/export meter - I can generate up to 6.4 kw (from a Proven Windturbine) but I am only diverting to a 3 kW immersion at present).  I can use all the surplus power in the house at this time of year as my primary heating is Economy 7 heating a 3000 l Akvaterm thermal store. Now, I have to reduce the flicker (which in a way I quite like as it is an indication that the system is working!)  so I will try Robin's Mk2a_PV_router_rev3a sketch if I can get my head around calibration!  Many thanks to you all who have contributed so much to this project.

It's always good to hear of another Mk2 Router that's working well.  Thanks for the kind words.  At this time of year, wind and hydro seem the only way to go!

Although the anti-flicker feature first appeared in Mk2a rev3, the Mk2a line has seen little use and is less refined than the Mk2i interrupt-based one.  The most refined sketch with standard 2-level AF logic is rev4b of Mk2i.  Rev5b of Mk2i has an alternative type of AF algorithm that needs no calibration but doesn't reduce the flicker speed by as much as a properly calibrated system running rev4b.  Unlike the standard AF algorithm, the one in Rev5b is ideal for a system with multiple dump-loads.

Mk2_PV_Router_mini_3 is a simple floating-point sketch that does not have anti-flicker.  However, it should not take much effort to add some simple AF logic to this code if required.  Floating point maths is fine if there's nothing else for the processor to do.

Links to all sketches are here

Thanks, Robin.  I have just ordered the components to build another Mk2 router so that I can try out various versions of your software and experiment with calibration.  I am reluctant to disconnect my first router as it is working so well!  My son will be home for a couple of weeks at Christmas and he is an enthusiastic C programmer so I will see if I can get him interested.  My son-in-law will also be with us for Christmas and his day job is installing and maintaining systems using huge capacitors to regulate power factor in industrial installations - I hope that I can get him involved as well.  I'll let you know how I get on!

Hi RichMc, I am after 3 sets of your PCB's, Have you any ?

Catty: Rich hasn't been active around here for some time, the last we heard he was poorly. Robin Emley (calypso_rae) has his own design and may be able to help you.

I built one of robins solar controlers over a year ago and has been working perfectly eversince. but yesterday my boiler went on the blink so i have no heating and now no hot water, as my immersion is controlled through the solar controler.

my question is could somebody add some code to robins scetch to allow a pushbutton that will switch on the triac for 1 hour, this will allow me to overide my solar controler in case of emergencies.

I am not very good at coding thats why i need someones help, this would also help other people in the same situation as me.

By far the easiest quick fix is to wire a switch rated at 10A or 15 A & 250 V in parallel with the triac, to switch the immersion heater manually. That will give you hot water even if the electronics of the diverter fail.

The units that Robin is now building have such an override switch.

Thanks Robert for the reply, I am making a set of PCbs tomorrow, the hard work has been done so thanks to all, Fantastic project with huge input. I am going for the original hand drawn sketch from July 2012 to start off and play with that, the anti flicker part .... well I'll see how that goes. Hope Rich makes a full recovery !

Catty, the original hand-drawn schematic is still perfectly valid, and has not changed at all.  It forms the basis of the PCBs that I have recently commissioned and which I will very soon be able to offer to constructors.  

All versions of the Mk2 sketch can be run on the same hardware.  One of the simplest sketches is described in detail at the very end of my online article about diverting surplus power.  The link to that article is on the OEM Home Page, just below the 'Welcome' paragraph and picture.

My MK2 has been working for over a year now and apart from a few weeks this winter has supplied all my hot water requirements. Thank you Robin and the other contributors for coming up with a circuit that was simple to construct, required no trouble shooting and just gets on with the job!

I recently added an LCD display to indicate the kWh diverted to the tank and this revealed that on sunny days with chilly evenings there is still a lot of power exported during the day when I'm at work after the immersion has cut off.

I've acquired a small storage heater, a Dimplex 0.85kW XL6N, with plans to divert power into this after the immersion has cut out. While it clearly has resistive heating elements I still need to investigate what other circuitry is inside since it may not like the waveform from the triac. Also there may be circuitry that somehow turns the heating elements on only during the economy 7 period which would need to be overridden. Has anyone tried supplying a storage heater with an MK2?

Has anyone tried supplying a storage heater with an MK2?

Yes, I tried using the 3.4 kW version in the Dimplex range and found it needed far more energy that my PV system could supply. Going for the smaller one sounds a much better idea. 

The Dimplex worked fine with the burst-mode feed from the triac.  I just turned the thermostat full on and it absorbed whatever power came its way - but there simply wasn't enough oomph to get the whole unit warm.  

I think the Dimplex would normally be fed from a circuit which is only live during the Economy 7 night-time, so there's no need to override anything. 

I posted a video about this on the day I got it going, it's at http://www.youtube.com/watch?v=TTgZxkW1sB8

Robin

I posted a question on the 'Talking Solar' website as to whether your MK2 would work with all types of utility meter, analogue, digital or smart.  As I haven't had a definitive answer, I thought I would ask the master himself ??

Thanks

Chas

Hi Chas,

The Mk2 Router simply balances the amounts of imported and exported energy as measured at the supply point, which is where the supply meter is located.  As many constructors have satisfactory demonstrated, this arrangement works fine with conventional meters, both digital and analogue. 

All known types of meter have a "sweet zone" within which energy can be moved to and fro without loss or charge to the user.  With non-reversing analogue meters, this zone may be quite large, around 2.5 Wh.  With most digital meters, it is 1 Wh, or 3600 Joules.  With some digital meters, notably those with 2-colour LEDs, the sweet zone can be considerably smaller, around 1250 Joules.

In its "normal" mode, the Mk2 Router requires just a couple of hundred Joules of headroom within which to work.  So it will clearly work OK alongside any of these kinds of meter.  In AF mode, the cycle rate  (aka "flicker" rate) is reduced by turning the output stage on in longer bursts.  When using this mode, it is important for the twin threshold levels to be appropriately set for the type of meter that is in use.   Calibration of the system is also a good idea, this being unnecessary when running in "normal" mode.

I have no idea how a "smart meter" works.  Providing that it allows some leeway within which the Router can operate, I can't foresee any problems.

Maybe you would like to mention the existence on my new website http://www.mk2pvrouter.co.uk/  in the other place. 

Thanks, Robin

Hi

In reply to the post   -  Submitted by pedben on Tue, 19/11/2013 - 09:37.  Second load on Robins MK2 diverter.

I have been considering using the solar electric when the cylinder is hot for another purpose, sorry if  I appear to be dim, please excuse me!!  You wrote :-

Connecting pin 9 of arduino to the common contact marked C on the Stat,one can switch between the existing circuit ie Robins circuit and another external SSR based system.
The 5v supply in this case is common to all .

Is that the normal situation, or do you mean connecting another cable to the arduino?? I had assumed that I could let the cylinder stat do the switching, is that what you are saying here?

So the output from the diverter, instead of going directly to the immersion, goes to the cylinder stat instead, which causes it to heat the immersion if the cylinder is cold, then switches to another load if the cylinder is hot, or is that too simplistic?

I get the idea that a Dimplex storage radiator would work OK, if it is small enough - about 1kW.

Thanks in advance

Chas

What pedben is saying is he is using the cylinder stat to switch the firing signal, that goes to the immersion triac when the cylinder is cold, away to another SSR when the cylinder is hot. Obviously, the second SSR will be connected to the normally open contact of the stat and to the Arduino common.

The problem I see with that is the cylinder stat contacts are designed for high current and might not switch the low current (15 - 20 mA) firing signal reliably after a period of time, unless there is a good wiping action as the contacts make.

I suspect he did it that way as it would be easier to run the low voltage low current firing signal to the second load than it would be to run high power wiring, even though it does mean that there are two SSRs / Triacs.

Thanks for your comments, I should have known better than to try to understand, as a non-electronica most of what you are saying is incomprehensible to me, but I do appreciate you trying.

My diverter set up is quite some distance from the immersion and would require quite some work to run an extra (even low voltage) cable to the immersion/cylinder area.

Best leave well alone I reckon,

My diverter set up is quite some distance from the immersion and would require quite some work to run an extra (even low voltage) cable to the immersion/cylinder area.

Can't you intercept the cable somewhere near to the consumer unit?  That's presumably where your immersion heater gets its power from.

Chas, what exactly do you want to do? You are already diverting PV power to your immersion heater, but I'm guessing at what else? Tell us a bit more detail and we might be able to help.

Thanks all for your patience!

I was thinking of what to do with the solar when it had heated my water to capacity.  Some comments have been made to use the excess to 'charge up' a storage radiator.

Robin's diverter switches the mains power to the immersion when there is enough solar to do so, it resides next to the consumer unit, which is about 30 ft from the immersion.

So at the immersion socket in my airing cupboard, there is power when the sun shines enough to power the immersion until the thermostat in the immersion says 'enough'. When the thermostat stops the power to the immersion, the power is still at the socket, ready to be used by another appliance.

I thought I could switch that power to a storage radiator by simply asking a cylinder thermostat to do the switching for me, so that the immersion heats up when the water is cold, and the storage radiator heats up when the water is hot.

This seems logical to me, how about everyone else?

It's logical enough, but I'm guessing (again) that the storage radiator you want to use is not close by the immersion heater.

Fortunately, Robin can come to your rescue. If you read his write-up, you'll see that he uses the concept of an "energy bucket" that is filled by the PV and emptied by the immersion. What happens to this when the cylinder stat opens? No prizes for saying it overflows. We can detect and use that to switch a second load, and Robin has done exactly that using the RFM12B radio. So what you could do is modify the diverter by adding a radio module, build a second electronic switch based on an emonTx with the triac output board added and locate this next to and switching your storage radiator.

He's published the sketches and links here: http://openenergymonitor.org/emon/node/1757
The "Mk2i_PV_Router_rev5.ino" is the main controller and the receiver sketch is "RF_for Mk2_rx.ino"

You probably want to read the supporting posts to make your own decision, but I think this is probably what you are looking for. Unfortunately, it is a bit more expensive than adding another connection to the thermostat (but probably a lot cheaper in terms of domestic upheaval).
 

Thankyou Robert for your input.

I am really on this forum as an imposter!! My Robin's MkII was built by a third party, but I did wire in it myself.

I pride myself as a reasonably competent amateur electrician (although as a species we are becoming forcibly extinct) assisting on at least two complete re-wires.

So I tend to be OK on the macro-electrics, whereas the micro-electrics seem to me to be a little like witchcraft!

In your post I was OK up to the term RFM12B radio, then you lost me.

This is why I tend to look for a mains solution, rather than the way I am being encouraged to follow.

From what I have read so far, I can find no reason why my solution, all be it clumsy and maybe untidy, would not do the job, AND not take me out of my comfort zone (I know I'm a scaredy cat).

Thanks again for everyone's time and help.

Chas, diverting surplus power to more than one load is an obvious way to refine a PV Router system.  As I type this, our DWH is already up to temp, and any remaining surplus is spilling over into the grid.  At some stage, I need to build a tidy unit which will allow this excess power to be used for a mobile appliance, controlled by RF.  As Robert has pointed out, my Mk2i Router code already supports this functionality.

Rather than using the cylinder stat to do something it was never intended to do, my preferred approach is for the Router to have two output stages, each with its own triac.  As only one triac will be on at a time, they can share a heatsink.  The Mk2i code can support any number of logical loads.  Each of these can be mapped to a physical load for which a dedicated pin is required on the processor, or the control signal could be transmitted by RF.

The RFM12B is a standard module which allows data to be transmitted and received by RF.  There's plenty of information about it in the Building Blocks Networking pages.

While working on the Mk2i line, I posted a simulation to show how multiple loads are dealt with.  At the time, it was more concerned with Anti-flicker regimes, but it demonstates how each load becomes activated when its stage in the heirarchy is reached.  When the stat for load 1 opens, that load effectively disappears, so load 2 takes over, and so on.  The paragraph 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...

If Robin's proposal frightens you, then provided you have a thermostat with a changeover switch, you could wire the feed from the diverter to the pole (common) of the stat, the n/c contact to the immersion (these two might need swapping over, but should otherwise be as you have it now), then you add the feed to the storage radiator from the n/o contact of the stat, with the neutral connected to the immersion neutral. Even though the storage radiator is only 1 kW, you must extend the wiring in cable that is fully rated to the level of protection provided for the immersion heater.

Can I remind you of a quote from Arthur C Clarke: Any sufficiently advanced technology is indistinguishable from magic.

Failed connection on Arduino analog pin 1 - current coil input

Dear all,

I have just had an infuriating problem on my installation. I noticed that when diverting power to the immersion I was drawing power from the grid. The degree of draw from the grid was proportional to the PV being diverted. The more I generated and dumped to the HW tank, the more I drew from the grid, up to a maximum of 500W. This was getting expensive.

I entertained all sorts of deep thoughts about software problems, triac failing, opto isolator not detecting zero etc etc .

Eventually the system failed all together and I had to take the lid off and poke around. 

i transpired that the CT connection to Arduino analog pin 1 had come loose. I had twisted the wires, tinned them then shoved them in the hole. This was a very snug fit 9 months ago, but not now. I have now used gold pins and soldered connections which should last longer. (Note earlier postings about tinning twisted wires, brass ferrules etc etc.)

Some code to detect failure modes would be useful though to protect us from instances like this. All connections are likely to fail eventually and those on the Arduino are delicate. When they do it would be useful to shut the system down

PeterC

I'd humbly suggest that the initial fault was a poor standard of construction. You state that all connections are likely to fail eventually. My experience after nearly 50 years in the industry - I started as a student apprentice in 1967 - is that improperly made connections fail quite soon, and properly made ones don't. It is very difficult to predict every possible type of failure mode, and to devise the appropriate automatic action. I suspect that if it had shut down, you would be complaining about all the energy you'd exported and having had to override the system to get some hot water.

Robert,

My initial construction was poor, which is why I mentioned it. There is a posting some way back that talked of soldering flexible cabling and I was hoping that my experience endorsed and reinforced that view for the benefit of others entering this forum who may be tempted to poke soldered wires into the Arduino sockets. 

My poorly made connection did last for 9 months or so and only became apparent when I took the unit off the wall to relocate it, presumably dislodging the connection. 

I still maintain that the original Arduino pins are not in the 'fit-and-forget' category. Anyone using them needs to take care and perhaps make them an early point of investigation in fault tracking. If my fault was repeated then they could unintentionally draw power from the grid as a result of a faulty input on the CT input. 

I hope these diverters are a success. A lot of work has been put into the development by many on this Forum, including you Robert. However as they become adopted more widely it is going to become more difficult to control the quality of the installations. If others make the mistake I made then that would be a shame. The dedicated board system reduces the possibility as screwed terminations rather than push-ins are used. However they are still a point of potential failure.

If it is possible to have a limited suite of codes for the most common faults such as out of tolerance signals on the analog input pins then that would help. If that is not possible then have some code to alert to the fact that significant power was being imported whilst the triac was firing. I was fortunate in that my Landis & Gyr E470 meter came with a remote display that I have next to the immersion neon in the kitchen so a routine visual check found it for me. If the meter is older and  in a cupboard with no remote display then this would not be so easily apparent.   

I would not have complained about exporting the energy, nor overriding the system to get hot water as the root cause was my poor connection.

Peter

Good morning Peter, for what it's worth.  

I've just taken some time off my Heliostat design, whilst I try and source two large worm wheels, unfortunately it looks like I'm going to have make them myself, my Meccano prototype works well, but not man enough for the job, and commercial ones are just too expensive, but that's an aside.  I wish I still had a metal lathe :-(

I too used one of Robin's MK2i sketches, and took I slightly different approach to ensuring that a fault didn't cost me money.  I added a hardware buffer between the Arduino output and the triac triggers, the buffer is enabled by the red light on the import meter.

The buffer I used was a 74HC365 (because I had one), it has two enable inputs, but I'm wasting one which is just tied to ground, but that could be connected to a 'watchdog' timer driven by a pulse from the processor for even more protection, at the moment the other input is driven low when the red light on the meter comes on, thus enabling the triac drive.

It may cause me to lose a little generated energy before the light comes on, and I haven't filtered out the normal 1Wh/Pulse, so there is potential for false enabling of the buffer for that short time, but it does give me a level of additional confidence, that I'm not inadvertently firing the triacs when I shouldn't.

I rather like this approach, and it does increase the chance that a fault in the system, won't cost you lots of money and it works for me.

It's worth a thought, it is an additional LDR, small general purpose transistor and some resistors, and additional opportunity for poor soldering!! Which with age and my eyes get worse, is becoming increasingly likely.

Hope this helps.

Just for fun, I've attached two pictures, showing the Heliostat prototype.

No comments about the quality of wiring, and soldering.  The stepper motor drive is from an old ICL printer.

Simon

Simon, your fail-safe method of driving the triac looks pretty sound to me.

The triac remains disabled until sufficient energy has been exported for the meter's LED to come on.  When this occurs, it effectively means that 3600J can be drawn without charge.  The Mk2 should never supply more than this amount to the load in one burst, so a safe start-up is assured.

Charge pulses only appear during periods of import.  During import, the Router's energy bucket will most likely be at zero, so the control signal for the triac will be firmly 'off'.  Briefly enabling the path between the processor and the trigger during a charge pulse will have no effect.

I have always felt it would be a good idea to monitor the meter's LED because the logic within the Router could then be synchronised to that of the meter.  By this means, no 'free' energy would be wasted at the start of each new period of surplus power becoming available. 

Hi Robin, it certainly works for me and I must take the opportunity to thank you again for sharing your solutions, it has been fun getting back into 'hands on' electronics.    

If I were to take the watchdog solution further, and there are probably dedicated watchdog timers available now, I would set something like 555 timer up as a Monostable Multivibrator, with the sketch putting it into the quasi-stable mode which would enable the output buffer, and as long as the sketch hits the timer with a pulse before the RC time constant is exhausted it would keep the output, enabled assuming the red light is on as well.  This way if the the processor locked up, or another fault as in Peter's case the output would be disabled.

I haven't done the watchdog circuit (I got diverted) and I think Robert's comments resonate with me, that there is only so much you can do to capture every failure condition, but with the Triac firing gated with a watchdog and the red light inputs, I think you could be very confident of staying in a safe firing mode at all times.

By the way Robert, I remember after University doing my EP1 training with Mullard Electronics and spending ages having my soldering tested and checked.  At the time it was really boring, but I have to say the techniques stuck with me, and when I fail to follow the physically strong connection before soldering, I nearly always regret it!!!!!

Regards and all the best

Simon

This way if the the processor locked up, or another fault as in Peter's case the output would be disabled.

The protection that a watchdog circuit can offer will depend on the nature of the failure.  If a CT were to go open-circuit for any reason, the processor would have no way of knowing that anything is wrong, so would keep on refreshing the watchdog circuit as normal.  If the energy bucket's level happened to be above the 'on' threshold, the triac would come on and stay on indefinitely, just as if a manually operated system had been inadvertantly left on.

Because the fail-safe mechanism that you have already implemented links directly to the LED of your supply meter, that arrangement seems pretty foolproof to me - better than any watchdog.

Simon,

Thanks for this. You have though ahead here and predicted a failure mode.  I agree that having a failsafe that is nothing to do with Robin's router makes sense. Especially as the meter is the beast that drives the bills.

Thinking this through a bit more it isn't just the terminations on the Arduino but the whole current coil(s) circuitry that could fail and cause intermittent faults. Robin has reduced the propensity for faults on his board very well but its the bits outside his box that are outside his control.  

In my case I used a solid toroid CT, not the split type as i wanted to reduce the chances of failure. I was comfortable disconnecting the circuit inside my consumer unit and threading this through the CT. I then soldered my burden resistor onto the CT and sealed it all up to minimise the chance of mechanical damage. However I can imagine the split type being knocked about depending on where it is attached. 

Could you sketch out the circuit for your design please? I am a mechanical not an electronics engineer. I know enough to be dangerous but would appreciate a design to follow. My system is back working OK now though but one broken wire and the meter spins again!

=====

(I am continuing my destratification tests and will issue the results soon. I have got a system working with an external pump. I want to offer a version with submerged pump inside the hot water tank for the more adventurous as this is more efficient ... provided the pump lives up to its speciafication when submerged at 70C. i need a few more sunny days)

Peter

Simon

I do not need your design after all, but others may and I think it would still be useful

I am fortunate enough that my relatively new Landis & Gyr E470 meter supplied by EoN has a remote display driven by a wireless link back to the E470. I have this remote display screwed to the wall in my kitchen next to the immersion heater switch.

It displays all the usual Smart Meter stuff. It usefully has a running total of exported energy, so a metric specific to us that will no doubt be used in evidence against us at tariff contract renewal.

There are 3 (Red Amber Green) LEDs on the front panel representing 3 different consumption thresholds.

I took the back off today and it was easy for me to solder a wire onto each of these 3 signals to these LEDs. I can now make triac firing contingent upon a HIGH signal on the green LED. This makes the cross-check simple and independent of Robin's code. A solder free solution would be a photoresistor. The display's LEDS are very bright.

I believe these Smart Meters are free upon request, mine was.T

Peter

It's good to know that my Router design works with a Smart meter. 

I've never been able to answer that question before.  I presume that a "Smart meter" is nothing more than a standard digital meter with an extra remote interface for the user to look at.

Robin,

Correct. It is a remote display with RF link back to the base meter in the meter box on the external wall

However the remote display has a push button interface and allows access to information that you cannot get from the meter itself

Here is a picture ... http://i.ytimg.com/vi/Dn5RQDb0r50/0.jpg

Robin,

(My last post does not appear to have arrived)

Yes it is a remote display, but it does have functionality that you cannot get at the meter itself. Display options for both gas and electricity (I have a smart gas meter too) I can enter tariff values so get cost and energy calculations and historical info as well as instantaneous. Traffic lights and a high usage buzzer all help "Household Paranoia"  

I cannot seem to enter the URL into this site. If you Google Landis & Gyr Smart Meter you will find it

Peter

Hi Dom,

The sketches can look scary but they are well written and easy to change.

I use two loads and the changes I made to Mk2i_PV_Router_rev5a can be found on the Talking Solar website.

http://www.talkingsolar.co.uk/index.php/forum/7-arduino-circuit-discussi...

It might help in seeing which parts of the well structured sketch need to be changed.

Regards, Keith

Keith,

I really can't recommend that anyone should go looking elsewhere in search of useful refinements for any Mk2 PV Router code of mine.  If useful new versions have been created, they should be posted here on the OEM forum where they can be peer-reviewed and checked by the author; not elsewhere in secret.  If your group wishes to modifiy my code in private, well that's your business, but please don't interfere with the well-established processes here.

I have visited the Talking Solar website on a few occasions, but have seen little to recommend it.  As I've mentioned on another forum thread recently, my latest Mk2 software is now to be found on my own website.  This code can be easily modified to run on any other Atmega 328 platform.

Robin

Keith,

Having just visited the Talking Solar website, I am disappointed to find there are various errors pertaining to my work.  For a start, it is stated that:

For those wishing to see all the versions of the Mk2 programs and development tools he has used they are listed here -

openenergymonitor.org/emon/node/1757

Some of these are Robins own work whilst others are gleaned from other OEM members.

That statement is incorrect.  All of the content of that thread has been supplied by me, that's what it's for.  That thread is a summary of my work, which is why Trystan has kindly allocated it 'sticky' status.

Rich McD has not been able to supply PCBs for some months.  However, a full range of Mk2-related items are available via my own website, at www.mk2pvrouter.co.uk.  Maybe you would like to include this link at some prominent place on your website.

If changes are being made to my Mk2 code, and posted online, I would very much appreciate it if those changes could be posted on the Open Energy Monitor forum where they can be peer-reviewed, and where I get the chance to see them.

Thanks, Robin

Hi Robin,

I'm sorry that I seem to have wound you up, it's certainly not my aim.

But I would like to correct a few things that I'm not convinced that you're not been fair about.

1)  Some of these are Robins own work whilst others are gleaned from other OEM members.

That statement is incorrect.  All of the content of that thread has been supplied by me, that's what it's for.  That thread is a summary of my work, which is why Trystan has kindly allocated it 'sticky' status.

------------

You asked me to add this in January 2013 because it was a team effort.

"Re: Mk2a PV Router (lean, mean and fast!!)
Submitted by calypso_rae on Thu, 31/01/2013 - 20:42.

Thanks Keith,

Rich has reminded me of my user details, and will PM you about what else I would like to be changed.  One point that I wanted to be corrected is that the phasecal algorithm was not my invention, it's been part of the standard OEM library code for as long as I've been around.  That one has already sorted."

I haven't got the PM now.

But you were happy with the changes that I'd made.

"Re: Mk2a PV Router (lean, mean and fast!!)
Submitted by Keith Walker on Thu, 31/01/2013 - 21:01.

Hi Robin,

I've made the changes to http://www.talkingsolar.co.uk/index.php/robin-s-mk-2-energy-bucket.

Can you have a look and see if it's what you're after?"

"Re: Mk2a PV Router (lean, mean and fast!!)
Submitted by calypso_rae on Thu, 31/01/2013 - 22:04.

Thanks Keith, that looks fine now."

I also seem to remember that the interrupt code was supplied by another member. So it was a team effort but with you as the leader and supplier of the idea. Which is what I had written and you had agreed. I'm puzzled.

----------------------------

2) "Rich McD has not been able to supply PCBs for some months.  However, a full range of Mk2-related items are available via my own website, at www.mk2pvrouter.co.uk.  Maybe you would like to include this link at some prominent place on your website."

I'll remove the link to Richard's board and replace it with your website.

But I've been promoting your venture for a while.

Nearly 5 months ago I posted ...

"Hi All,

Robin is going commercial. He's designing new hardware and will be selling kits or fully built systems. See his site below for details.

www.mk2pvrouter.co.uk

Regards, Keith"

I also posted this just over 2 month ago ...

"Hi All,

Robin has started a commercial venture.

www.mk2pvrouter.co.uk/

Good luck Robin :-)

Regards from us all at Talking Solar."

3) As regards to making secret changes to your code.

The changes that I've made for a small sweet zone for my meter were suggested by you on this site. So no modifying of your code in secret there.

The additions that I've made for the multiple loads are just an minor extention to your code which I'm sure I've posted to the openenergy forum. If not I apologise. But again no secret changes.

I tried to post the changes on her but your forum seems to dislike Windows 7 and the latest version of IE.  And I couldn't cut and paste. That is why I posted the link. Tonight I couldn't even log on so I typing this on a four year old Linux netbook.

---------------------

Anyway I don't wont to get in a slanging match with you but I just wanted to but my side forward.

I'll remove Rich's board details and replace it with another link to your site. That will be three :-) I hope they generate some sales for you :-)

My site was set up to share ideas on maximizing solar power usage. I used google to search for "solar power excess power" etc and found nothing. Goggle knows best. I now know that I should have searched for "solar power immersion heater". It's paid for three years. After that it will quietly disappear but may turn into a facebook group to chat about the lighter side of solar power.

Stay Chilled, Keith

Hi Keith,

I am not able to moderate any messages myself, but I'm sure that those who can will be able to remove any multiple copies. 

My preference is simply that anyone who wishes to contribute to the Mk2 debate should do so via the OEM forum.  By that means, all new contributions are kept within one place and any misunderstandings can be nipped in the bud. 

If anyone is following my postings via this forum, they will already be aware of the website that I have recently set up.  Having a whole section on your own website that is dedicated to my work, but without my knowledge, agreement or consultation seems a surprising way to go.  I don't see how it can be helping anyone.

Robin

My original Mk2 design was intended to run on a 5V Arduino, hence the input range of the ADC was 5V.  For the emonTx V3, the supply voltage is 3.3V hence the ADC range is correspondingly less.  In each case, the ADC reference has always been set to its default value of Vcc.

The Atmega processor can also use an internally generated 1.1V reference for its ADC.  This reduced voltage range would be a better match for many CTs which are only intended to operate up to around 0.3V rms max.

Running the processor in this alternative manner is very straightforward and appears to give excellent results.  I recall trying to do this a couple of years ago but without success.  Maybe the breadboard was causing poor connections.  Or maybe I was in too much of a hurry ...

Anyway, with a more robust setup, this alternative way of working seems to be giving good results now.  A handful of  component values need to be changed:

The Vref needs to be 0.55V rather than 2.5V.  With a 5V rail, this can be achieved using 27K and 220K in the op amp circuit, rather than both values being equal.

The voltage source will need to be dropped to a smaller signal, the actual values being dependent on the transformer that is being used.  With a 6V AC transformer, I'm using 2k7 and 100R.

With the reduced ADC range, the burden resistor needs to be smaller.  Rather than 150R for measuring up to around 4 kW, I'm now using 47R.  

When using analogRead(), the only change that's needed for the sketch is to include analogReference(INTERNAL); within setup().  When using the interrupt-based code, the value 0x40 needs to be changed to 0xC0 within the ISR.

The results below show a pair of voltage and current waveforms using this alternative arrangement when the CT is clipped around a cable through which 2 kW is flowing.  They don't look much different than before, but the CT is now being used in a much better way.

No of cycles recorded = 1
cycleCount 2352,  samplesRecorded 53
|                                      21                                       |
|                                 2     1    v                                  |
|                            2          1         v                             |
|                         2             1             v                         |
|                      2                1                 v                     |
|                   2                   1                    v                  |
|                   2                   1                      v                |
|                   2                   1                      v                |
|                    2                  1                       v               |
|                      2                1                      v                |
|                          2            1                 v                     |
|                              2        1            v                          |
|                                   2   1      v                                |
|                                       12v                                     |
|                                   v   .1    2                                 |
|                               v       1         2                             |
|                          v            1             2                         |
|                       v               1                2                      |
|                   v                   1                   2                   |
|                 v                     1                   2                   |
|                v                      1                   2                   |
|                v                      1                  2                    |
|                v                      1                 2                     |
|                    v                  1             2                         |
|                         v             1         2                             |
|                               v       1     2                                 |
|                                    v  12                                      |
min_V 223,  max_V 819
min_I1 519,  max_I1 525
min_I2 263,  max_I2 782

In my original Mk2 design, the Vref output from the op amp was mid-way between its power rails, and this arrangement has always worked well. 

With the alternative scheme that I posted yesterday, the Vref output is very close to the ground rail, and the LM358 device may not work well in that configuration.   So although the new version appears to give similar performance when a large current is flowing, it may be that this is not a viable way for the input stages to be operated.

I recall the output-range limitations of the LM358 op amp being raised years ago.  To get around this difficulty, an alternative (non-DIL) device has been used by some constructors.

Having checked the TM358 datasheet, it seems that this device can drive its output close to the ground rail, so it should be able to generate a 0.55V rail without any problem.  With this system in place, the level of background drift  appears to be worse that I have previously seen, so something is not behaving as expected.

In all measurement circuits that I've seen to date, the reference voltage for the sensor circuits is referenced to Vcc, and so is the ADC.   With the scheme that I was suggesting, the ADC uses the internally generated bandgap reference, but the sensors continue to use a stepped-down version of the supply voltage.  Maybe this is not a good idea.

By re-configuring the op-amp connections, it may be possible to use a buffered version of the internally generated 1.1V reference for the input sensors. Has anyone has tried this?

My recent interest in using the Atmega's internal 1.1 V reference for the ADC is in connection with a new PCB that I've commissioned for a 3-phase version of my PV Router.  Details of this board, and initial performance results, are on the "3-phase" page at www.mk2pvrouter.co.uk

To allow one or more SSRs to be used for controlling the loads, the new PCB can be run at 5 V.  As this voltage level is outside the specified working range for many CTs, it would seem better to operate the ADC (and hence the CTs) using the processor's internal reference voltage of 1.1 V if possible.

Using a modified version of this PCB, I've been able to buffer the internally-generated 1.1 V reference and use this to supply the reference rail for the three pairs of voltage and current-sensors.  Although this scheme does work (some results are attached), the amount of background noise that I'm seeing is considerably more than when the ADC is referenced to Vcc in the conventional manner (results on website). 

On the next version of this board, I intend to include a jumper so that the Vref rail for the input sensors can be derived either from Vcc or from a buffered version of the processor's VREF pin.  Users will then be able to choose whichever version of the hardware is best for their needs.  For an accurate representation of the current that is being measured by the CTs, the INTERNAL (1.1 V) reference may be best.  But for a better signal-to-noise ratio, the DEFAULT (Vcc) setting of analogReference() would probably be a better choice.

Although the LM358 op amp is able to work close to ground, it cannot drive its output near to the Vcc rail.  This means that it can only be used to buffer the VREF pin when analogReference() is set to INTERNAL.  Unfortunately, the pin-compatible rail-to-rail TS912IN device from ST is no  longer available in DIL form.

I have copied and pasted a brief PM conversation I had with Robin and his reply.  I definitely have an issue where with three loads, and a 'cloud over' scenario and where third load is only just on, that I can have the loads on and seemingly under control (i.e, being pulsed) and the supply meter LED is also pulsing.

I am playing with the interLoadSeparationDelay_cycles, but I've also brought a routine in, to monitor the supply LED and make sure I don't turn on the loads if the supply meter LED is not on. 

Has anybody else experienced this?

Having upgraded to the MK2i- 5e that's the one I've stayed with, but as you'll see in my rather long PM, i first noticed it with MK2i-5b

regards  Simon

New
calypso_rae 28/08/2014 - 23:37
Hi Simon,
Yes, I agree entirely with your thinking.  If multiple loads need to be turned off, then this should happen as quickly as possible.  A 0.5 second delay is a somewhat crude way to do this, but this mechanism does seem to do a reasonable job for most of the time.
Reducing this "hold-off" value from 25 to say 10 mains cycles would probably be a good idea.  I've never experimented with this setting.  There has to be some delay in there so as to allow the removal of the first load to take effect.  If two loads were to be removed when only one would suffice, that would be unhelpful.
Feel free to raise this concern on the forum.  Maybe other people have already made changes in this area.
Regards, Robin

My original PM…….

Good morning Robin, sorry for the PM, but I thought initially I’d talk directly to you, rather than the forum, but if ends up that there is value in this discussion we can move it there.  My hypothesis is that interLoadSeparationDelay_cycles = 25 should not be used in the reduce load algorithm?

Be patient with me, I am finding it quite hard to articulate, but I’m questioning the ‘backing off of loads algorithm’ when there is a quick change in PV – cloud coming over and just enough PV to be switching on 2nd load fully, and 3rd load just on.

1. Firstly, I had been running the MK2i - 5B on Arduino uno, adapted to have 5 hard wired outputs, 4 of which are regularly active.  For the purpose of this question, I upgraded to the MK2i – 5E, just in case you had made a change which rectified this perceived problem, and again adapted this for just three outputs, to keep the problem simple.  I think 5, even if you are not using them, further exacerbates the problem.

2. Bottom line is that I seem to get to a situation where the meter LED is flashing i.e importing, and the loads are being activated.  My understanding of the supply meter LED is
a. Fully on, either exporting, or has been in the ‘sweetspot’ for circa 4.5 minutes –“ see saw effect” i.e no nett energy movement seen stays in the range of 0 - 3600J .  I think I may have noticed one flash before it goes fully on after the 4.5 minute see saw scenario.

b. Flashing, means importing which is an unfortunate reality costing money and wrong when the loads are also on.
3. I have an AMPY 5196A supply meter, and my sensing circuit though based on your original idea has slowly deviated, but I’m confident it’s working effectively.

4. I have a 4kW PV array, the primary load is the immersion heater (3kW), followed by two oil filled radiators at 2kw each, all of which have their own thermostats.

5. When the primary load is on, it is rare that there is enough PV to fire up the second load, the house currently takes about 600 watts of background energy.  It has happened a few times, highest measured generation at 3.82kW, and I might have noticed this effect then, but too rare to be sure.

6. In the situation when the immersion is up to temperature, with only one additional load i.e bog standard MK2i with noOfDumploads = 2, the system  seems to work correctly, however….

7. In the situation where the immersion heater is up to temperature, and noOfDumploads = 3, and there is enough PV to switch on load 2 fully, and load three partially, when a big cloud comes over, I think that load 3 is turned off immediately, then with interLoadSeparationDelay_cycles = 25, then load 2 is turned off 0.5 second later, in which time at 2kw heater has consumed 1000 Joules.   So, do you need interLoadSeparationDelay_cycles on switching off loads, I think I can see the benefit of it on bringing a new load in, but I’m suggesting it might burn energy, which you might not have, taking you back to import which may not have been necessary.

8. When the cloud goes, the energy bucket fills up, the loads are turned back on and because the software  takes control immediately the meter light is off waiting for that 4.5 minutes timeout  “see saw sweet spot zone”.  If in this period, the light levels drops slightly, again I think it turns off load 3 immediately, which may only just be being triggered, waits 0.5 seconds to turn off load 2, in which time 2kW is dumped in that half second which is another 1000 joules.  If this happens 2 or three times, I think we fall out of the bottom of the real supply meter energy bucket and we have a pulse on the supply meter.

I’m currently running in fixed timer mode, but prior to that free running, just to see whether I could change anything?  I’ve attached the opening dialogue from the serial monitor, weather is currently cold wet and raining PV generating about 300 Watts, which is offsetting house load of 600 Watts, result import of circa 300i’sh Watts

I’m sorry this is rather long, but hopefully readable have you got any thoughts with your intimate knowledge of your code? Or am I totally off kilter??

Regards Simon

The trouble with monitoring the meter's LED is that the (albeit small) financial penalty has already been applied by the time that the LED changes state.  The ideal scenario would be to monitor the meter's LED so that the Router's operation can be synchronized to it.  Then there would be no need to pre-charge the energy bucket because the Router would always know the precise state of the equivalent accumulator within the supply meter. 

When the amount of surplus power changes suddenly, it's difficult for any system to react quickly and accurately - and with minimal flicker.  If you can come up with a better way of controlling multiple loads in such situations, I'm sure that many correspondents will be interested in this. 

The router can operate correctly when the meter's LED is either continuously on or continuously off.  If you switch off a 3kW kettle just before the next consumption pulse is due, there's a good chance that the router's see-saw motion will start up without the LED coming on.  But if a consumption pulse has just occurred, the meter's LED is likely to come on while the energy bucket is filling up to the pre-determined point where diversion starts to occur.  During this phase, a small amount of surplus power is being lost to the grid, this being an unfortunate consequence of the two systems not being synchronized.

Totally agree, and I'm not being critical of the MK2 code at all, and if I do find a better solution, I'd be very surprised - ecstatic actually.

No, my monitoring, which may end up as a flight of fancy was to stop what  I'm getting which is multiple pulses, whilst the loads are on.  I still don't understand it, I'm not sure it is the delay I mentioned, but it only happens with two loads being actively controlled at the 'same' time.  i.e when the PV is generating a little more than 1 loads worth, forcing the software to switch both loads, as clouds go over.  The multiple pulses implied totally out of sync.......I'm getting to understand your code a lot more now, so some good has come from it.

If you remember originally I had the meter light tied to a tri-state buffer, which blocked the firing signal if it wasn't on, but I took that off, maybe time to bring it back.  No where is it????

I found that you do need delays between the triacs as otherwise the loads turn on and off much too fast. I have about 13 loads and without the delay you get rapid switching on and off of nearly all the loads.

Note some meters will flash the led when exporting. (Constant on is when in anticreep mode)

Note some meters will flash the led when exporting. (Constant on is when in anticreep mode)

With a meter that only charges for consumption, as in the UK, a short flash of the LED undoubtedly corresponds to a chargeable amount of consumption.  If the diversion logic were to take too much energy before allowing the system to recover, then the meter would be right to charge the user and hence isolated pulses would be seen.  I cannot believe that pulses would ever be seen during periods of genuine export.

If a meter is configured to charge for energy flow in both directions, as in many parts of the world, LED pulses would presumably be seen during continuous periods of export and import.  Many overseas correspondents have installed Mk2-type diverters in order to prevent their surplus power from being exported.  With such systems, it would be good to know how the meter responds to reciprocating energy flow when the energy state is maintained within the sweetzone of the meter, and charges are thereby avoided.  I would expect the LED to be either 'on' or 'off', but not flashing or pulsing.

Tinbum: With so many loads in your system, it seems likely that any pulses at your meter are due to over-consumption, albeit for only short periods.  It you could post your code here, correspondents would then be able to understand how your control mechanism is actually working.  Your code may be based on "Mk2i", but it has clearly been altered in significant ways. 

If you are not willing to post your code here for inspection by interested parties, then any results that you obtain with it are meaningless to the rest of us.

Robin,

What on earth are you on about?

I have a meter that flashes when I am exporting but does not increase.- full stop!

The code I was referring to was the code you did for me in the first place with no modification at all! Try it for yourself in practice- I had to add delays to stop rapid sequential switching of the triacs on and off. 

What on earth are you on about? ... The code I was referring to was the code you did for me in the first place with no modification at all!

Tinbum: the code that I supplied for you two years ago was a trial build for multiple loads before I formally released Mk2i Rev5.  It was never intended for long-term use and should have been replaced with the proper Mk2 Rev5 version when that became available.  Instead, you have continued to use that original trial version and have since modified it substantially to meet your particular needs. 

That's OK for your own personal use.  What is not OK is to suggest that any code which you have modified - or any results from it - have anything to do with me.  That code can no longer be realistically described my "Mk2i"; it is now your own code for which you have sole responsibility.  I don't understand why you are so reluctant to post it online for others to see and inspect.  If your modifications have been properly implemented, you will get due credit for them.  If not, then you will learn from the experience.

A couple of months ago, I upgraded some of your code for you by merging in the control logic from Mk2i Rev 5 and chopping out goodness knows how much extra stuff which I didn't think had any business to be in there.  I would certainly not recommend using that build for any serious investigations

I had to add delays to stop rapid sequential switching of the triacs on and off

How can the code be "unmodified", yet include extra delays which were not in the original version ???

Robin,

I answered a general question about delays between triacs. This is not your forum.

This has absolutely nothing to do with any code I am running. As I have stated before my code is available and I have made it available.

I am absolutely fed up with your attitude, start listening to what people actually say and stop trying to shoot people down. Just because you haven't seen something it doesn't mean it doesn't exist. Examples being;

1 The energy bucket of a meter always isn't 3600J

2 Some meters will NOT work with your code.

3 LED's can flash when exporting.

Once again you are ranting over something that doesn't exist. Go back and read what has actually been said.

Tinbum - I asked for your code a while ago but unless I missed a post, haven't seen it or any link to where it might be found. Are you able to post a link now? I am very interested to see how you are switching your loads, in particular your heat pumps.

Also, I think it is a bit harsh to be using that kind of tone with Robin. The work he has done on this forum and for all of us in terms of writing code and developing both software/hardware is quite phenomenal. And all but the hardware is provided completely free of charge.

I for one am extremely grateful to Robin, and Robert and all the other chaps on here who are extremely patient and helpful when dealing with beginners like me.

Ben,

I sent the code to you, at the e mail address in your pm, on 24th August at 12.37 our time.

Yes it may seem harsh but I am sick to the teeth of everything I have discovered being dismissed/disbelieved or blamed on my code.  It has absolutely nothing to do with my code at all. I am not stupid enough to test a meter etc  using a code that has timers in etc etc.

I know exactly how my code works and any limitations it has, after all, this code has been adapted over nearly 2 years of actual practical use with many loads, 13 at present, and many different types of load. As written it is a specific code for my use, for my specific loads and my specific load priorities and load sequence. The extra stuff  that doesn't have any business in there is there for a reason, it all starts to get quite complicated.

As I have said in the past I am happy to give people the code but it can't be used just out of the box as every ones requirements are different. It can only be treated as a basis to start from and I don't have the time to adapt it to each persons individual needs though I am happy to give some help on a one to one basis. 

I have never said that this code is Robins or his Mk2i, or that he is responsible for it and I have never used it for any investigations. It's use (not working) may have resulted in me starting investigating though.

Like I have, you are looking at adapting a code for your use but it doesn't mean that Robin has to write it, approve it or approve of it.

Like you, I admire Robin for his work, as I have previously stated on this forum and Robert for all the help he has given to me and everyone else.

I must be remembered, however that this is a forum where people should work together and take things forward. I could have simply kept quiet about the size of energy buckets or that I had found a meter that didn't work with Robins diverter but thats not the idea of a Forum. These are problems that we should be looking at a way round, not dismissing because they don't 'fit in' or go against previous perceived knowledge. We are all here to learn. 

Ben,

I see you've just found it!!

Nick

Apologies! The email never arrived in my inbox but I just checked my spam folder and there it is - no idea why it was marked as spam, but as I said, apologies for not noticing it - and thank you very much for sending it through. 

I understand what you are saying, and I agree that the forums are for learning. I am very new to all this so am struggling to keep up with the discussions but hopefully things can remain civil and you can both continue to offer help and advice to those who are new to all this!

I can't wait to get my diverter built and operational as we are heading into the summer months down-under...

Hi Robin, Tinbum and Sumnerboy.

Without trying to be the opposite of a moderator  ---  “provocateur”??, …..

…..the question as to whether a meter can flash without it incurring cost is an important one, has anybody else seen, or can confirm, this to be the case.  My understanding was that each pulse is chargeable.

I have an Ampy 5196A in which I think the “sweetzone” is 3600J, and with Robin’s MK2i -5e code, I am seeing pulses in  normal operation (that’s what started this recent thread), but I have modified it to add one extra load for this test.  It seems less about the number of loads per se, but the number which are active at one time, even though only one of those loads can operate at one time, the problem I think I'm seeing is when two loads are being switched. i.e enough PV to support two loads

Modifications are :-

1. const byte noOfDumploads = 3
2. const byte physicalLoad_1_pin = 10;     
3. const byte physicalLoad_2_pin = 11;
4. const float powerCal = 0.0748;              
5. const float voltageCal = 842 / (float)679;

Set the new load pins to be outputs
6. pinMode(physicalLoad_1_pin, OUTPUT);
7. pinMode(physicalLoad_2_pin, OUTPUT);

At start up added in the set force loads to be OFF section
8. digitalWrite(physicalLoad_1_pin, physicalLoadState[1]);
9. digitalWrite(physicalLoad_2_pin, physicalLoadState[2]);

Added new loads to Update all other physical loads section
10.  digitalWrite(physicalLoad_1_pin, physicalLoadState[1]);
11.  digitalWrite(physicalLoad_2_pin, physicalLoadState[2]);

I’m not using RF, so that boolean is set to false, but that was how the original 5e code came set.

Absolutely no other changes and I’m seeing pulses, and because it only happens in a boundary condition, very hard to observe.  Condition being:-
1. 1st load at 3kW on but no longer drawing energy, up to temp.
2. 2nd load on, at 2kW and drawing energy.
3. 3rd load marginally on, being switched, at 2kW
4. PV on the cusp of supporting that load and varying considerably – clouds!!!

I have tried:-
1. Removing the  interLoadSeparationDelay_cycles in the decreaseLoadIfPossible routine, it didn’t remove the problem, as Robin thought.
2. I’m in process of adding a Meter LED monitor, with a “software crowbar” which only fire triacs if meter light on, I think I’m on the right track, but the LED is coming in on A3, so I’m having to work within the interrupt routine, so slow, lot’s of learning.
3. I’m also thinking could it be my hardware, two of the loads are on the original triac drive, the third using a solid state switch which has an external snubber circuit, and I wonder whether that is too slow to switch?

Any thoughts would be welcomed.

I know I'm not anyone else but to expand on what I've seen;

The thing I have found is that meters can be different and many can be configured in lots of different ways.

I was very surprised to come across a meter that will pulse the LED on export without the display increasing. The meter is a Landis and Gyr E110. No code or diverter at all involved- just wired in reverse.

If you PM your e mail I'll send you a video of it doing it.

EDIT

Apologies, file was to big to e mail- its at;

http://youtu.be/NNfcfLhiG50

Thanks for that Tinbum,

It certainly does show the Landis and Gyr E110 behaving as you described. i.e pulsing whilst exporting, and with no increase in units.  

Interesting.

Assuming that that is 'vanilla' product, and the same for L&G E110's then I can't take what I thought was standard for standard.

My Ampy doesn't behave like that, but it 's good to know that the assumption that all meters show solid on export isn't true.

So I'm still looking for my issue, but thank you for taking the time to show that to me.

Regards Simon

"Assuming that that is 'vanilla' product, and the same for L&G E110's then I can't take what I thought was standard for standard."

I think you've hit the nail on the head there. As I understand it, more or less any meter can be programmed to the customer's specification - the customer in this case being the energy supplier - and "identical" meters will no doubt be the same hardware, but the firmware and hence the operating modes can be very different.

What we've seen is most meters flash when importing, most meters show a steady light in anti-creep, most meters show no LED when exporting and ignore exported energy, most meters have a 3600 J quantum inside which no energy transfer is registered. But not all. We've heard of meters with very small energy quantum, we've heard of meters that charge for export, and now we've heard of a meter that flashes but doesn't charge for export.

Tinbum, that's an interesting demonstration of how a digital meter can pulse when current flows in the reverse direction, and a useful contribution to the debate about how meters can be configured. 

The role of the Mk2 PV Router is to maintain the energy state of the premises within the penalty-free range that is permitted by the supply meter.  While the energy state remains within this range, I would not expect to see any activity at the LED, however it has been configured.

Those blinking lights..

I need some alternative views; I can’t think what else to try. 

I have been convinced that my MK2i code modified for multiple hard wired loads is allowing the supply meter LED to pulse whilst the loads are being controlled. 

From a conversation with Tinbum, it was clear that not all meters behave in the same way, but I’m pretty sure that my Ampy 5196A, follows the norm. i.e

• LED pulse is 1Wh of energy.
• LED on either for anti-creep, or exporting.
• Before entering anti-creep, my meter gives one pulse.

Trying to watch the lights is nigh on impossible, so I felt obliged to write a monitor mainly using Robin’s code.  So now I can see:-

• Unconstrained energy movement in bucket from last cycle
• Which load is active
• Status of Supply Meter LED whilst showing
    o Energy in bucket at point of LED transition.
    o Time in milliseconds of event

This has clearly left me somewhat perplexed; indeed I can prove that I have situations where when loads 2 and 3 are active that the supply meter is pulsing, but to be more scientific I came up a couple of levels in thinking to be sure I wasn’t chasing ghosts. 

• I disabled all the outputs and ran the code – result was supply meter LED stayed on all the time and was logged as such.
• I re-enabled the loads with only enough PV to partly satisfy load 0, so no switching, and periodically the LED turns off and back on again, the period ranged from a minute between Off-On cycles to about 3 minutes, but remains consistent with a given set up, i.e amount of PV, internal parameters of the code.  The Off-On cycle last for 1.65 seconds, give or take +/- 0.05. I’m assuming this is a chargeable event.

The code appears to be working impeccably, looking at the energy, it looks in the zone.  As a test I reduced powerCal to 0.01 from the 0.0548 to make sure that the internal energy units were smaller than the real world that did slow the Off-On event down to the lowest repeat period, but it’s still there.  I have currently blocked firing of the loads if the supply meter LED is not on, to stop repeat pulses, but it still switches off and on.

Is it a feature of the meter?  Am I being daft?  Any thought would be welcomed.

Here is an example of 2 logs either side of the supply meter LEDOff event:-

Sketch ID:      Mk2i_PV_Router_rev5e_3Loads with_Monitor.ino
ADC mode:       125uS fixed timer
Output mode:    normal
Priority load:  local
Auto-select?:   yes
Extra Features: none
powerCal =      0.0548
phaseCal =      0.50
  capacityOfEnergyBucket_long = 3284671
  midPointOfEnergyBucket_long   = 1642335
  postMidPointCrossingDelay_cycles = 0
  interLoadSeparationDelay_cycles = 25
>>free RAM = 908

Example 1 - load 0 Only - 
-17.13,     Active Load,   0,
-1.92,     Active Load,   0,
-16.59,     Active Load,   0,
-20.07,     Active Load,   0,
2.94,     Active Load,   0,
65.35,     Active Load,   0,
-51.61,     Active Load,   0,
************************** LED OFF **,  energy in bucket = 1613356  Time mS    976928
-25.72,     Active Load,   0,
************************** LED ON **,  energy in bucket = 1671245  Time mS    978531
16.68,     Active Load,   0,
-17.14,     Active Load,   0,
2.67,     Active Load,   0,
9.12,     Active Load,   0,
68.04,     Active Load,   0,
0.00,     Active Load,   0,
-14.07,     Active Load,   0,

Example 2 – Load 0 off, loads 1 and 2 on and active.
6.68,     Active Load,   2,
12.49,     Active Load,   2,
************************** LED OFF ** ,  energy in bucket = 1610375  Time mS    192461
527.83,     Active Load,   2,
1744.56,     Active Load,   2,
************************** LED ON **,  energy in bucket = 3284671  Time mS    194063
-247.18,     Active Load,   2,
-1005.83,     Active Load,   2,
-123.24,     Active Load,   2,
19.52,     Active Load,   2,
-20.14,     Active Load,   2,
63.10,     Active Load,   1,
0.08,     Active Load,   1,
-2.63,     Active Load,   1,
-26.91,     Active Load,   1,
0.84,     Active Load,   1,
7.42,     Active Load,   1,
-16.21,     Active Load,   1,
21.29,     Active Load,   1,
-5.82,     Active Load,   1,
-8.29,     Active Load,   1,
-60.18,     Active Load,   2,
100.26,     Active Load,   2,
-61.56,     Active Load,   2,
13.04,     Active Load,   2,
-36.12,     Active Load,   2,
35.52,     Active Load,   2,
-1.84,     Active Load,   2,
-6.59,     Active Load,   2,
-39.90,     Active Load,   2,
13.52,     Active Load,   2,
3.81,     Active Load,   2,
************************ LED OFF ** ,  energy in bucket = 1609707  Time mS    219882
1671.94,     Active Load,   2,
************************ LED ON **,  energy in bucket = 3284671  Time mS    221493
910.79,     Active Load,   2,
-846.97,     Active Load,   2,

Simon, how often are you displaying the energy state?  If it's only once per second, you may not be seeing the detailed picture. 

Some of my Mk2 sketches have a second energy bucket that has LED in its name.  Maybe you could print out that value whenever any LED activity happens.  That second accumulator has no min or max limits.  It would be helpful to print its value out in Joules rather than in integer energy units.

While checking the performance of a meter, I think it would be much better to be using only one load.  When two loads are operating sequentially, there is some 'dead' time before the "active load" can change during which there could be some LED activity.  The Mk2 logic can only maintain the required the energy state while it has control.   There may also be some part of the AF mechanism which prevents subsequent transitions occurring within a certain period.  These should be set so as not to interfere with your testing.  That mechanism was an attempt to prevent transitions from occurring too rapidly - but it is very likely to result in unwanted meter activity, as you are seeing

Have you looked at my Digital Meter Emulator sketch, which is on my Summary Page.  I regularly use this one when calibrating any new hardware.  When the pulse rate is the same as my spare Ampy meter, correct calibration has been achieved.  The optimal powerCal value can then be transferred to the relevant Mk2 sketch.

My DME sketch appears to mimic the Ampy meter in both forward and reverse directions, but the anti-creep simulation was never completed.

Hi Robin,

 the   "power = energyInBucket_4led_long * IEU_to_Joules_conversion;" is what I'm printing first in the line, and it's printed in line with "if ((cycleCount % CYCLES_PER_SECOND) == 7)"  It was in your words a useful place to print something :-)

The first example has only one load, and the PV levels were too low for any other loads to get a look in.

I'll try the Digital Meter Emulator again, I have used it the past, but Mmmm  not convinced it will say anything but I will try.  Sun going down now, will try it after it's stopped to get a simple answer with no PV.

I think your sketch is working fine, everything I've looked at seems good, I do wonder whether a configuration of an Ampy meter is possible where it does do an inverse pulse during periods of export, or am I just dipping out of the sweetzone?  How would I know

OK, so that sketch is displaying the level in the energy bucket every second.  For your purposes, I think it would be better to display this same value only when the LED changes state.  You need to catch every on->off transition because they are chargeable events, IMHO.

During consumption, if your powerCal value is correct, LED pulses should occur approx. every 3600 Joules. 

During operation in 'normal' mode, when SP is available, no LED activity should occur because the Mk2's logic can keep the energy level well within the meter's sweet-zone..

When in AF mode, it's all to easy to stray outside this penalty-free zone.  However, this behaviour can be used to your advantage.  By slackening the AF criterion, the meter's LED should start to pulse in synch with the cycling of the load.  Then, as the AF criterion is tightened, the LED should either stay permanently on or permanently off.   The two AF regimes in Mk2 code have different criteria.  For Mk2i Rev5, it's based on time (a certain number of mains cycles); for all other versions, it's based on the separation of two energy thresholds.

With tightly set AF limits, and not too much delay when activating your adjacent loads, I feel sure that your system can be encouraged to work as intended. 

Mystery solved!

Mia maxima Culpa, I committed the cardinal sin of assuming something and we all know what that means!

I even stated it in an earlier thread, where I said I'm sure that my current and voltage sensors are working well, well the current coil which was off an E.on home meter is very very non linear.  

This resulted in the filling of the bucket with smaller 'real' energy packets, and emptying with larger "real" energy packets, based on the size of the current being measured.  i.e low current from PV filling bucket (cloudy), higher current Immersion, radiators when emptying.  So the software was happily switching around the 1700 Joules mark in software, but slowly sliding out of sync with the real electricity meter.  

So sorry Robin for  even challenging your software, now the linearity problem has been addressed  it is working perfectly, as is the previous MK2i - 5b code.

So thanks to all who helped,

Simon

Did you have something like this Efergy transducer (I can't call it a CT due to the other components present)? That's clearly designed to be a non-linear rectifier, but (and I suspect this is what you meant) a proportionally larger output at low current to give increased sensitivity there. I would guess there's a lookup table in the Efergy software that linearises the numbers post ADC conversion. Maybe even, you have a badged Efergy unit?

Interesting that the unhelpful effects of non-linearity have now actually been observed.  I've been harping on about this for ages without ever seeing the consequences myself.  The standard CT seems remarkably able to maintain good linearity when operated at higher voltage levels than are intended.

I wonder how effective the magic sensor is for this new kid on the block?  Maybe that's why they need a 200 Watt guardband!

I don't think the guard band would safeguard the system.  

The problem of the non-linearity in my current coil and circuit was that I repeatedly slipped out of sync with the meter 'bucket', when the PV was just on, so low current towards export and loads were high so high current towards import.  It was that non-linearity which got me. i'e proportionally larger output at low current.  (Robert mine isn't a Efergy transducer, but I haven't played with it in anger yet to see what it is).

I think in the past you used to use the term biased toward either import or export, mine is now biased towards export, however your algorithm picks up the heat, perfectly after the midway point, I tend not to use anti-flicker, so it works well.

One thing I have done is to leave the supply meter LED monitor routine in, and only allow the triacs to fire when the Supply meter LED is on.  I originally did this in hardware with a tri-state buffer, and may re-introduce that, but for now, I cannot fire any load unless meter light is on, which gives me a 'warm feeling', well actually not :-))))

As I understand it, the Solar iBoost system aims to divert all but 200W of the surplus power, which is the same as having an export bias of 200W.  My Mk2 system, when equipped with a linear front-end, is sufficiently well balanced that no biassing is required.

The response time of a Mk2 system is around 30mS.  If any alternative product says that a guard band is needed to avoid being charged when loads change unexpectedly, that just shows how slow their system is to react.  From their FAQs:

When does my Solar iBoost start putting energy into my hot water tank?
As your PV array starts to generate in excess of your household power requirement the Solar iBoost will begin to "dump" energy into your hot water tank. For example if you have 2.2kW of export energy then the Solar iBoost will dump 2kW into the immersion to heat your tank of water. There is a buffer of 200W to ensure that the Solar iBoost deals smoothly with the changing use of household energy and the PV array's generation thus avoiding any draw from the grid.

If there were to be a small amount of residual drift between the meter and a Mk2, it would most likely be below the anti-creep threshold of the meter and therefore ignored.

I rest my case :D

From their advertising material, it looks as if their current transformer is attached to a transmitter - the "sender". They must measure both the absolute value of power and its direction (even if they make assumptions about a unity power factor), so I'm wondering whether the 200 W guard band is down to the way they are obliged to measure that. If they have a transmitter measuring current, it cannot be continuous measurement due to the regulatory requirements of the band in use (unless of course they have hijacked a band reserved for radio microphones or something like that). Nor can they transmit the rms value because they need phase information as well. So I'm postulating that they transmit a short burst of the current wave at intervals, so that they remain within the channel occupancy limits, and it's that which limits their response time. It's just an idea that might be completely wrong.

Hello,

I need some guidance with the PV diverter if someone could help me please, i have the basic schematics functional and now i need to know what soft to load on my Arduino Mega board, and how to make some fine tunings.

My PV power is 2.4kw, and a 2kw heater. I have an AC unit that is working all day, and the max divert amount of power is maximum 500-1000w.

​Thank you in advance!

I assume that you have read the article about Robin's diverter? There are links in there to the sketches, and there's a guide in the introductory article about which sketch to use. Having chosen one, you'll need to make changes to the pin allocations to suit your hardware.
There is a lot about tuning and calibration in the comments near the top of the sketch, but feel free to ask again if anything is unclear.

Hi,

I'm lost with so much versions and i don't know what to choose. I not need any improvement like wireless module, only to divert the surpluss PV production. 

Thank you!

hi, I read the article, but because i'm not understanding some terms and operations right now i have doubts what to choose and how to fine tune the setup. I need basic functions of the diverter without Wifi module or other improvements (led status) that don't affect the basic functionality. The bad parts is i don't have any spare energy meter to see if the setup is working good.

Thank you!

I think rev3a is the version you want.
You will need to change:
Line 89: enum operatingModes operatingMode = ANTI_FLICKER; // <-- select the desired mode here
  if NORMAL makes your lights flicker, then ANTI_FLICKER should reduce the problem.
Line 91: #define CYCLES_PER_SECOND 50
  to suit your supply
Line 223: const float powerCal = 0.061; // <---- powerCal value
Line 238: const float voltageCal = 800 / (float)679; // <-- the first number is the output range of your ADC when 240V AC is being measured
Line 259: const float phaseCal = 1.0;
  Instructions for setting these values are in the comments.

_________________________________________________________

If rev3a does not suit your supplier's energy meter (if you cannot balance the load to give zero export when you would otherwise be exporting less than 2 kW), you could use the latest (rev6a) that has an adjustment for the meter characteristic (SWEETZONE_IN_JOULES). If you do not have the radio module, you will need to remove (or comment out) rf12_initialize( ... ) at line 371 and send_rf_data( ) at line 652. Everything else that you do not use can remain.

The other things you might have to change are:
Line 49: #define CYCLES_PER_SECOND 50
  to suit your supply
Line 50: #define SWEETZONE_IN_JOULES 3600
  to suit your energy supplier's meter
Line 208: const float powerCal_grid = 0.0346; // for CT1

_________________________________________________________

You do not need a spare energy meter. If you can see your energy supplier's meter, that is all you need. The diverter will try to balance the energy diverted so that there is zero average energy flowing in from the grid. For example, if you are generating 2.4 kW and using 1 kW in your house, when the diverter is working correctly it will divert 1.4 kW to your heater and the supplier's meter will show zero import.
You should try to calibrate the diverter as accurately as you can, but a small error will not give you a big problem, because the diverter is balancing the load around zero and it is only measuring the difference between energy imported and energy exported.

Which terms in the article do you not understand?

Hi, i will try to load and modify the software with your indications and i let you know if everything is ok. I was lost with those operations with setting powercal, and all other ops like antiflicker etc....

Now with your explanation everything is ok, i manage to set the setup and i hope it will work good!

Thank you very much!

Hi Ali72,

Many different versions of my Mk2 PV Router code have been posted.  They all do the same basic job but the later versions have some extra features that you may find to be useful.  My Summary Page has a complete list of all these sketches.  This Building Blocks article by Robert has a table which summarises what they all do.

The simplest sketch is Mk2_PV_Router_mini_3.ino.  It may be best to try this one first on your hardware. 

Robin (calypso_rae)

Hello all,

I uploaded the mini 3ino. version to my Arduino, and it's working, the energy meter is staying or move slightly from left to right, but when another appliance  is starting the diverter not put the load to off state and it still consuming from the grid. There is a setting that i miss?

Thank you!

From what you write, it seems that the basic operation of the diverter is correct. But if you do not have enough PV power to support all the loads (except the heater that is the diverted load), then what you are seeing will indeed happen. If you do have enough surplus power, then there is a problem. The only possibilities that I can think of are that either your CT is not measuring the current properly (and that could be that the calibration is wrong), or that it is in the wrong place. Is the diverter CT on the grid side of the point where all the loads (including your diverted load) are connected? Does your hardware follow Robin's original circuit diagram http://openenergymonitor.org/emon/sites/default/files/Mk2_CircuitSchemat... ?

Hello, 

yes, i use that schematics from your link, the calibrate is ok, right now i have an import  of 90watts from grid and the serial output is tell - 96 . If the PV is generate 1,5kw and the appliance load is 0,8kw then the serial output is positive, 710watts.

In this condition the Diverter load is working ok, and my 0,7kw Oil heater is working, but if another appliance start and the total load exceed the total PV power then the serial output is reporting me the amount used with - , but the triac is not going off and continue to import 0.7kw of power from grid.

Is this ok?

"If the PV is generate 1,5kw and the appliance load is 0,8kw then the serial output is positive, 710watts." That is correct operation.

"... but the triac is not going off and continue to import 0.7kw of power from grid." That is wrong. If your total load without the heater (the one that is controlled by the diverter) is greater than the total PV power, then the diverter should be off.

Again, is your CT in the correct place, like this: http://openenergymonitor.org/emon/sites/default/files/mk2typical.png

Hi, yes the CT is clamped to the cable that came from grid meter before to enter in the junction box, when i export power the serial output is with positive, aca 740w, and when i import is with minus.

The readings are correct because i have an OWL PV meter system that is counting the import and export and have the same output like PV diverter, very close readings.

Only problem is the triac it is not off when i importing, i will check the schematics again to see where is the problem, but if the readings are ok, i think is some problems in the software side with the triac on off sequence!

My hardware is Arduino mega, but i think is not a problem.

Thank you !

I've just skim read the posts from Ali, I belive he said he's using the Arduino Mega not the Uno dosn't he need to change some of the pin connections? (or better still use an Uno) I have no experence of the Mega, but something is nagging me from a previous post.

And Hi everyone.

Hi Ali, (and Rich!)

For the Mk2 Router to work as intended, the input sensors have to be set up correctly.  An easy way to check this is with my RawSamplesTool, there is a link on my Summary Page.

When a decent amount of power is flowing, the display should look something like this.  I do this check for  every system that I build.  This particular display has three traces, one for voltage and two for current.  For the basic Mk2 diverter, such as the mini_3, only one current sensor is needed.

4
3
2
1
0
No of cycles recorded = 1
cycleCount 852,  samplesRecorded 53
|                                    2 1.                                       |
|                              2       1.    v                                  |
|                          2           1.         v                             |
|                       2              1.              v                        |
|                    2                 1.                  v                    |
|                  2                   1.                      v                |
|                  2                   1.                       v               |
|                   2                  1.                        v              |
|                    2                 1.                         v             |
|                      2               1.                       v               |
|                           2          1.                  v                    |
|                               2      1.            v                          |
|                                   2  1.      v                                |
|                                      1.2                                      |
|                                  v   1.     2                                 |
|                             v        1.          2                            |
|                        v             1.             2                         |
|                    v                 1.                2                      |
|                v                     1.                  2                    |
|              v                       1.                   2                   |
|             v                        1.                  2                    |
|            v                         1.                  2                    |
|             v                        1.                2                      |
|                 v                    1.           2                           |
|                       v              1.       2                               |
|                             v        1.   2                                   |
|                                   v  2.                                       |
min_V 177,  max_V 844
min_I1 510,  max_I1 511
min_I2 248,  max_I2 773

Hello,

This is what i got, it's ok or not.

illis() now = 0
recordingMayStartAt 5000
4
3
2
1
0
No of cycles recorded = 3
cycleCount 254,  samplesRecorded 179
|                                      c.v                                      |
|                                      c.    v                                  |
|                                      c.         v                             |
|                                      c.             v                         |
|                                      c.                 v                     |
|                                      c.                      v                |
|                                       c                          v            |
|                                       c                        v              |
|                                       c                       v               |
|                                      c.                      v                |
|                                      c.                      v                |
|                                      c.                 v                     |
|                                      c.              v                        |
|                                      c.        v                              |
|                                      c.   v                                   |
|                                     vc.                                       |
|                                v     c.                                       |
|                            v         c.                                       |
|                       v              c.                                       |
|                   v                  c.                                       |
|              v                        c                                       |
|          v                           c.                                       |
|            v                         c.                                       |
|              v                       c.                                       |
|              v                        c                                       |
|               v                      c.                                       |
|                  v                   c.                                       |
|                       v              c.                                       |
|                             v        c.                                       |
|                                  v   c.                                       |
|                                      c.v                                      |
|                                      c.     v                                 |
|                                      c.         v                             |
|                                      c.              v                        |
|                                      c.                  v                    |
|                                      c.                    v                  |
|                                      c.                      v                |
|                                      c.                      v                |
|                                      c.                      v                |
|                                      c.                          v            |
|                                      c.                     v                 |
|                                      c.                   v                   |
|                                      c.             v                         |
|                                      c.        v                              |
|                                      c.  v                                    |
|                                    v c.                                       |
|                                v     c.                                       |
|                            v         c.                                       |
|                       v              c.                                       |
|                   v                  c.                                       |
|                v                     c.                                       |
|               v                      c.                                       |
|               v                       c                                       |
|           v                          c.                                       |
|              v                       c.                                       |
|                v                     c.                                       |
|                   v                  c.                                       |
|                        v             c.                                       |
|                             v        c.                                       |
|                                   v  c.                                       |
|                                      c. v                                     |
|                                      c.     v                                 |
|                                      c.         v                             |
|                                      c.              v                        |
|                                      c.                  v                    |
|                                      c.                       v               |
|                                      c.                          v            |
|                                      c.                           v           |
|                                       c                          v            |
|                                      c.                      v                |
|                                       c                      v                |
|                                      c.                v                      |
|                                      c.             v                         |
|                                      c.        v                              |
|                                      c.  v                                    |
|                                    v c.                                       |
|                               v      c.                                       |
|                           v          c.                                       |
|                      v               c.                                       |
|                  v                   c.                                       |
|              v                       c.                                       |
|             v                        c.                                       |
|               v                      c.                                       |
|           v                          c.                                       |
|             v                        c.                                       |
|               v                      c.                                       |
|                    v                 c.                                       |
|                        v             c.                                       |
|                             v        c.                                       |
|                                   v  c.                                       |
minVoltage 151,  maxVoltage 872,  minCurrent 509,  maxCurrent 514

Raw data from stored cycle: <Vsample>,<Isample>[cr]
179, <<< No of sample pairs
525,510
558,510
588,511
617,511
644,510
671,511
701,511
733,511
747,510
771,511
811,511
851,511
861,512
844,512
841,512
833,512
830,512
816,511
806,511
809,511
812,511
796,511
749,511
743,511
712,510
668,511
636,510
600,511
565,511
528,511
490,511
460,511
429,510
404,511
376,511
343,511
318,511
290,511
262,510
245,510
193,512
165,511
151,510
163,510
173,510
168,510
199,510
214,510
194,512
185,511
214,511
245,510
249,511
291,509
312,510
347,512
387,511
425,511
459,511
499,511
535,511
566,511
591,511
615,511
645,511
678,511
704,511
739,510
765,511
781,511
791,511
818,511
809,511
803,510
806,510
806,510
808,510
844,511
868,510
847,512
802,510
763,511
772,511
739,511
693,511
674,511
631,510
592,511
555,511
519,511
484,511
455,510
426,510
398,511
371,510
345,510
314,511
282,511
259,511
233,511
226,509
198,510
209,510
218,511
210,512
189,514
162,511
156,510
195,510
219,510
224,509
220,510
267,511
288,512
326,511
349,511
384,511
424,511
463,511
500,511
538,510
568,511
595,511
619,510
647,510
676,511
706,511
741,511
758,511
781,511
827,511
841,510
866,511
868,512
872,511
867,512
860,513
844,512
806,511
798,511
809,512
793,511
741,511
728,511
702,511
660,511
631,510
588,511
552,511
511,511
476,510
447,511
421,511
395,510
366,510
336,511
303,511
280,510
254,511
238,511
197,510
172,510
184,510
212,510
215,511
202,511
161,510
159,510
190,510
206,510
214,510
234,511
270,510
281,510
323,511
359,510
394,511
428,510
467,510

I have, i think a shortcircuit between pin 6 and 5 on Moc driver, and now when i plug to 220v the input and the output to the load, the load remains off not on like before and i have a 0.32 -0.99 readings, i think this is the normal behaviour ?

What are those 0.32 -0.99 readings - I cannot understand what you mean there.

Your voltage input looks fine, if somewhat distorted on the peaks, but the current is very small. What was the actual current when you took that reading above? Which current transformer are you using, and what value is the burden resistor? It might be necessary to get more signal by increasing the value of the burden resistor, though that will mean you will have to recalibrate the sketch.

You should not make a connection to pin 5 of the MOC3041. The data sheets marks it as "NC" - No Connection - and a note says "Do not connect - Triac substrate". If you have connected it, I think it is likely that the internal triac will not operate correctly and might well have been damaged. You also need to make sure that you have connected the external triac, the BTA 41, correctly as under a very light load, the load current will be carried by the MOC3041 and the BTA 41 will not have enough current to latch.
I cannot think of an easy way for you to test the driver on its own, but you can easily test the complete output circuit with a 9 V battery and a resistor of about 470 Ω. Connect the battery and resistor in series with the input (pins 1 & 2) of the MOC3041, with the positive to pin 1. If the output turns on, and turns off when you remove the battery, it's probable that the output switch is working.

HI, the readings that i posted was with a broken wire from CT sensor, after repair it looks good and the 0,..-0,... readings disappeared and instead the corect import at that time was displayed aka -134. After i remove the shortcircuit from the MOC driver, the triac stay finally off when the readings are with minus and i hope today will have some PV output to see if the diverting is working ok.

Thank you all for support, have a good day!

It's funny how the manufacturer tends to know how their device should be used. You should ALWAYS follow their data sheet examples.

And I've checked Robin's circuit diagram too - that is also correct to the data sheet.

3kw immersion/mk2 blowout - what happened next....? Real life example

There was a discussion back in the early days of mk2 around short circuit protection for the triac - in the end deemed too expensive vs low triac cost and (relatively) easy swapout.

Last weekend my immersion failed/shorted due to normal age/corrosion issues whilst my early version mk2 was running. here's what I found.

Old style fuse wire went off with a bang in the consumer unit,and the mk2 stopped working.

On opening up the box, I found the triac switched live had burned through at the crimped switch terminal on the override switch. No signs of overheat/damage to the triac.

With hindsight looks like the fuse wire could have been incorrectly spec'd (but no easy way to tell - will replace with a breaker) but reassuring that heatsink/triac could hang in there regardless. With a new crimped live was back up and running in no time !

[Duplicate post deleted - Moderator (RW)]

Interesting, I've heard about a few cases of crimped connections failing.  Apart from the screw connectors which are rated at 25A minimum, all power connections in Mk2 systems that I build are soldered.  So in the event of an immersion heater becoming shorting out, it would be a direct battle between the fuse/circuit-breaker and the triac as to which would survive the longest.

Providing that the immersion still presented some resistance, the overload current would only be present for a fraction of the time.  The system may be able to struggle on in this state until the surplus power exceeded some limit, and then something would have to give.

On opening up the box, I found the triac switched live had burned through at the crimped switch terminal on the override switch. No signs of overheat/damage to the triac.

I wonder why the circuit failed at this point.  Power doesn't normally flow through the override switch.  Maybe that connection had already quietly expired.

I'm trying to calibrate a arduino pv router using the sketch cal both displays. I dont have a display but it says it also sends the information to the serial port. I've set the correct analogue pins for my voltage and current sensors. And I've made sure the pin saving hardware is blanked out. The program runs. Prints some information on the serial page on the connected laptop but doesn't appear to show current draw on my ct. Any ideas where I'm going wrong?

There isn't a sketch of Robin's called "cal both displays". Exactly which one of Robin's many sketches are you using?

The sketch cal_bothDisplays_1.ino is available from my website via the Downloads page.  It is a version of my interrupt-based Mk2i PV Router code which displays the measured value for either of two channels via the 4-digit display that is supported by my own PCB. 

The sketches on my website are intended for people who are using my own hardware.  The same software will run on any Atmega 328 platform such as the emonTx or Arduino Uno, but the IO port allocations may need to be changed.

If anyone wants one, my original 1-phase Mk2 PV Router PCB is available for the cost of the postage.  This has a minor tracking error which is easy enough to fix.  Kits of parts, including for the display, are also available via my Shop page, as are my email details.

All of the software on my website is available in an equivalent form (for the emonTx) via my Summary page on this forum.

That's it the cal_bothdisplays_1.ino sketch. The sketch it linked to had to be copy and pasted to Arduino as it didn't download just display it on the web page. I've changed the ok pins to what I have set up and not much happens. Should it give constant readings or is it a one time measurement? Thanks

Sorry, I only know the sketches that are posted here, and what I think Robin is saying is if you buy his hardware, he'll support that. But if you buy your hardware from elsewhere, then it's up to you to get it working, as he cannot know exactly what you have and how you have connected everything.

The Easily website that I use appears to have changed the way that files are accessed.  Rather than being downloaded with a randomized name, the file now opens up in a new window.  This may be a better way for the requested information to be accessed.

Should it give constant readings or is it a one time measurement?

Looking at the section of code in question, the data for the 4-digit display is updated each second with the appropriate value in Watts.  The same data is sent to the Serial Monitor by means of a Serial statement in the called function, configureValueForDisplay().  This process will repeat endlessly, once per second, while the sketch is running.

        // Once per second, the contents of the selected accumulator is
        // converted to Joules and displayed as Watts.  Both accumulators
        // are then reset.
        //
        if(perSecondCounter >= CYCLES_PER_SECOND)
        {
          perSecondCounter = 0;   
          int powerInWatts;
          
          if(powerChannel == GRID) {
            powerInWatts = energyThisSecond_grid / IEU_per_Joule_grid; }
          else {
            powerInWatts = energyThisSecond_diverted / IEU_per_Joule_diverted; }
          
          configureValueForDisplay(powerInWatts);
          energyThisSecond_grid = 0;
          energyThisSecond_diverted = 0;
        }
        else
        {
          perSecondCounter++;
        }

OK my bad. After a post on here about what I wanted to achieve I was thinking that buying an emon tx shield would allow me to do pv diversion, energy and temperature monitoring. So I bought the parts then realised it was not a simple job to make it all work. I then decided to just use the shield for the pv diversion for the current and voltage sensor, and have bought an emon v3 and emonbase for my energy monitoring, keeping the 2 seperate. I was thinking I just had to adjust the sketch with regards to the io pins, calibrate it and away I go, using an ssr as the output. This is when the problems started. I have since come across this post, and after looking at the schematics for both devices realise the input electronics is completly different.

Right from the start of this project in 2012, the DC content has been removed from the stream of voltage samples by subtracting a DC offset value.  This value is determined by a Low Pass Filter which is updated ever mains cycle.  During each mains cycle, the difference between each new V-sample and the DC Offset value is determined and added to an accumulator.  By the end of the cycle, these 'signed' offsets will have largely cancelled themselves out.  1% of any residual value is fed back into the filter.

The above description is based on how this logic has always worked, which is not as I intended.  My intention was that the feedback should be 1% of the average offset of the ~50 samples during the preceding mains cycle, not 1% of their total.  When 50 values are summed, the average value will be 0.02 of their total.  Hence the required amount of feedback will be 0.01 x 0.02 = 0.0002, rather than 0.01 as has been always used to date.

With such a large amount of feedback, the DC Offset is unlikely to remain at a constant level as was intended.  Instead, it jumps back and forth around the correct point.  So why hasn't this caused a problem with the operation of any Mk2 PV Router code?   Although the DC offset at any one moment may not be correct, any consequential error will soon be lost when averaged over several mains cycles.  However, the system will clearly work better when the DC removal scheme is set up as intended, hence my posting this update now.

The latest version of my original 'Mk2' code which uses analogRead() is Mk2_PV_Router_mini_3.ino.  The port allocations for this code were made for the emonTx V2.  I have today updated the LPF section of this code as above, and checked its performance on an emonTx v2 (photo).  The new version is attached as Mk2_PV_Router_mini_3a.ino.  The only change of significance between these two versions is that " * 0.01" has become " * 0.0002".

For the later 'Mk2' code which is based on integer maths, the feedback portion was derived using a right-shift of 2^6 = 64.  The exact value does not matter; 2^7 would work just as well.  But this amount of right-shift is only appropriate when the average DC offset value is being used, rather than the total.  When applied to the total of 50+ values, the feedback portion should be correspondingly smaller.

The latest code in my 'Mk2i' line is Mk2i_PV_Router_rev6a.ino.  Most of the Mk2 code on the Downloads page of my own website is based on this Mk2i line.  The LPF implementation is identical for both.  To correct the amount of feedback in this code simply requires that ">>6" be changed to ">>12".  The updated section looks like this:

if (polarityConfirmedOfLastSampleV != NEGATIVE)
{
  // This is the start of a new -ve half cycle (just after the zero-crossing point)
  // which is a convenient point to update the Low Pass Filter for DC-offset removal
  // The portion which is fed back into the integrator is approximately one percent
  // of the average offset of all the Vsamples in the previous mains cycle.
  // 
  long previousOffset = DCoffset_V_long;
  DCoffset_V_long = previousOffset + (cumVdeltasThisCycle_long>>12);
  cumVdeltasThisCycle_long = 0;

The same change will be appropriate for any "continuous" code that is based on any of my offerings to date.  As far as I am aware, the text string ">>6" does not occur anywhere else in my code.  So wherever this string appears in this context, it would seem sensible to change it to ">>12" at the earliest opportunity

My apologies for the inconvenience caused.