PHASECAL and Serial Statements

This may sound like a surprising pairing, but they both have a significant effect on our real-time code. 

The Mk2 sketch that I posted a few days ago loses marks in each of these areas.  For a start, it does not include PHASECAL, probably because I didn't really understand it.  Although my triac-based build appears to be working fine, and created another full tank of hot water today, its performance would no doubt be improved if I had phase-shifted the voltage samples to align with the current samples.  For a resistive load, I should be seeing a Power Factor of unity, but without including PHASECAL, that is unlikely to be happening.  RW has suggested that I read up on this topic, which I intend to now do without further exposing my lack of knowledge in this area.

My sketch also contains a display line which appears on the screen every few seconds.  OK, we all know that Serial statements are relatively slow, but a few short ones can't really be making very much difference can they?  Well, take a look at the attached file, made using the display tool that a posted a few weeks back, and think again ...

Also attached is a display showing a single mains cycle that has been sampled using two independant voltage sensors.  One is a standard plasticised adaptor, the other is a large chassis transformer.  I wouldn't like to say which one is better, but their waveforms are clearly different.  If nothing else, it seems likely that each of them would benefit from a different value of PHASECAL.

Robert Wall's picture

Re: PHASECAL and Serial Statements

As I understand it, the call to Serial.. returns immediately but the data still has to be sent, and carefully timed to maintain the baud rate, and there's only one processor so the processing has to steal cycles from the sketch.

You will almost certainly need a different value of PHASECAL for different makes and model of transformer. Depending on its performance, you might also find that the value for PHASECAL will depend on the mains voltage at the time. (here shows the X-Y plot of an adapter as the voltage is varied from 185V to 253V IIRC). For those who can't view the video: Basically, as the voltage increases, what started off as a straight line (output tracks the input exactly) opens out into a loop. The harder you push the iron, the bigger the phase error because you've permanently magnetised the iron and so the magnetism does not follow the same path falling as it did when it was rising (the B-H loop). If you don't get near to saturation, then the loop is small and the phase shift correspondingly small.

[The telecom adapter appears to show less of the 'wiggle' at the crossing that is characteristic of saturation and a phase shift).

calypso_rae's picture

Re: PHASECAL and Serial Statements

Robert, please could you clarify what you mean by "pushing the iron".

My 'ironwork' sits within the primary and secondary coils of a dedicated 240V mains transformer.  The primary coil is connected to the mains, and the secondary coil is driving a resistive load of approx 100k.  I don't see any other way that I could be pushing it, either more or less hard.

Robert Wall's picture

Re: PHASECAL and Serial Statements

It's not you who is "pushing the iron", it's the transformer designer. When you magnetise iron, the process is not linear. The magnetic flux increases more and more slowly until it can take no more, when it is said to be 'saturated'. This is a characteristic of the material - the 'magnetisation curve' . (See http://en.wikipedia.org/wiki/Saturation_%28magnetic%29).

When you take the magnetising force away, not all the magnetic flux disappears. The iron has become permanently magnetised. (The flux that remains as called the 'Residual magnetism'). Then, as you magnetise the iron in the other direction, it starts from a different place. This mechanism is what gives you Magnetic Hysteresis.

Now the voltage that comes out of the transformer is related to the rate of change of flux. So looking at the hysteresis loop, H is the magnetising force resulting from the primary current, and the rate of change of flux B gives you the output voltage. Clearly, the output voltage is going to be different to the input.

The transformer designer tries to get the maximum out of his transformer by working the iron as close to saturation as possible, because that way he can use the minimum amount of iron and so keep his costs down. But the further he drives the core into saturation, the more distorted the output voltage becomes.

If you run your A.C. adapter at (say) 110 V (as I have done in the tests I've carried out), you find the output almost exactly tracks the input with very little phase lag and distortion.

 

calypso_rae's picture

Re: PHASECAL and Serial Statements

If you run your A.C. adapter at (say) 110 V (as I have done in the tests I've carried out), you find the output almost exactly tracks the input with very little phase lag and distortion.

OK, Robert, thanks for that clarification.

So if I were to connect two small transformers in series so that each of them only sees 110V, and just use the output from one of them, I would then get nigh-on perfect results ...

Robert Wall's picture

Re: PHASECAL and Serial Statements

I would then get nigh-on perfect results ...

... if you get them to share the voltage equally. But you only get half the voltage out, so you might just as well wire the secondaries in series as well.  I don't guarantee the result would be perfect, but it cannot be worse. Of course, you'd need identical, or at least very similar, transformers in order to share the voltage properly. To do that, you might find you need to wire the secondaries in parallel.

calypso_rae's picture

Re: PHASECAL and Serial Statements

Sorry, Robert, maybe I'm missing the point here.

The standard approach is to take a single 240V AC adaptor or transformer and pot down its output, often by 10:1, for supplying to the Arduino.  If there were two similar transformers in series, then each would only see 120V, and each would only provide half of the output signal.  For the same sized signal at the Arduino, the resistive divider would just need to be less.

If running a standard transformer on 50% supply would give a near-perfect voltage waveform, then that could be a good reason for taking this different approach. 

My PV system needs to be as efficient as I can make it.  It needs to pay its way for many more years to come!  

stuart's picture

Re: PHASECAL and Serial Statements

Hi Robert,

Did I mention interrupts ?

 

I re-jigged (technical term!) the code you provided to start using interrupts, this not only allows you to use the serial statements without affecting the measurements, but also then allows very evenly distributed measurements over a period of time.

 

Your code as it stands will vary its reading points over the AC wave because each loop through the code takes different amounts of time, additionally because the code is making an estimate of when the positive zero cross occurs that also happens at different points along the cycle, I think I measures values around 5 to 50VAC before the zero cross code kicks in.

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

stuart

My code ? ? ?  Which code is that?

JBecker's picture

Re: PHASECAL and Serial Statements

If you run your A.C. adapter at (say) 110 V.......

Take a 400V AC transformer (these are readily available with different output voltage ratings, e.g. Hahn BV E 1 304 2735 with 21V output) for 230V grid voltage. This also gives a perfect output.

Using inputs or outputs in series (or individual tappings on the output) can give load-dependant results.

BR, Jörg. 

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

Now I think it's me who's missing the point!  Your resistive divider is 165kOkms in total, the power dissipated in the resistors is 5 mW. The power dissipated in the transformer core is probably 2 orders of magnitude greater than this (The standard Mascot adapter draws 10 mA at 250 V = 2.5 VA, so - I didn't check this - probably about 1.5 W). I don't think saving a few milliwatts in the divider will make much difference - you will probably save more in iron loss by running the transformer at the lower flux density, the justification for that is the Mascot adapter draws 7.5 mA at 225 V, so as expected not a linear relationship.

I just wrote "wire the secondaries in series" to avoid the need to recalculate and obtain a new resistor.

Robert Wall's picture

Re: PHASECAL and Serial Statements

JBecker

Unfortunately, at 415 V only open-type at 'industrial' sizes (at corresponding prices and VA ratings) are readily available in the UK.

calypso_rae's picture

Re: PHASECAL and Serial Statements

For anyone who has ever wondered what PHASECAL is all about, but not been quite sure where to start because it all seems so complicated, why not check out my attached "PHASECAL For Dummies" presentation.

A few days ago (as Robert will testify), I knew absolutely nothing about this intriguing topic.  I'm not now claiming to be an expert, but you may find a lighter-than-normal approach to this heavyweight topic to be of some interest.  From the outset, my objective has been to understand more about my own Mk2 setup for PV Control, but those findings should be equally relevant to anyone who is using the standard OEM V&I sketch.

Within a few minutes, you too could be creating those impressive Lissajous Figures (hope I've spelt that right) on your own system.  All you need is an Arduino.  If you already have a working system for measuring power, you can then find out whether its performance could be improved by tweaking PHASECAL a bit this way or that, or whether it needs more drastic remedial action, as my system appears to do.   Maybe my new mains transformer is to blame, who knows. 

The attached zip file contains a 6-page MS Word document saved in two formats; the sketch by which all results were taken in both 'debug' and 'normal' modes; and four files of results from simulation, test rig and our grid-supply point.

Hope it's of use to someone :)

calypso_rae's picture

Re: PHASECAL and Serial Statements

I've just spotted the Building Blocks piece entitled

Explanation of the phase correction algorithm

which I see has had 800+ reads.  What I don't understand is why anyone would want to use a value of PHASECAL that is outside the range 0 - 1.  Within that range, we're applying linear interpolation between two known values, which makes perfect sense to me. 

For anything outside that range, it would surely be better to delay one of the samples (whichever occurs first) until the corresponding pair of samples that you require for the instantaneous power calculation have become available.  Then, using a PHASECAL value within the range 0 - 1, you can interpolate between those two samples, so as to get the precise value that you need.

There should never be any need to predict where the voltage waveform is likely to be going.  Just store the relevant sample of current until you know where the voltage has been. 

Phase-advancing circuits are fine in theory but seem poorly suited to this kind of application where Voltage and Current samples appear in endless alternation. 

 

 

 

JBecker's picture

Re: PHASECAL and Serial Statements

Robin,

very good point. This has also puzzled me for a while. Why extrapolate when interpolation would also be possible? Extrapolation can in theory give completely wrong sample values. But, on the other hand, especially for the voltage samples, we can with very good probability assume, that the next voltage sample will also 'ly' on the sine curve determined by the preceeding samples. So the extrapolation is a very good 'guess'. It only fails if the mains voltage is suddenly shut off.

This could be the reason why it is done this way ?!?   

Regards, Jörg.

Robert Wall's picture

Re: PHASECAL and Serial Statements

Try exchanging these two lines in calcVI( ) and see what value you need for PHASECAL

sampleV = analogRead(inPinV);                 //Read in raw voltage signal
sampleI = analogRead(inPinI);                    //Read in raw current signal

There are some notes in the software that accompanies App Note AVR465 about the phase correction:

Due to multiplexing, there will be a delay between subsequent data chennels, as follows:

     Delay = [ 360 degrees * f(mains) ] / [ 3 * f(sampling) ]

At 2400Hz sampling rate, this means that fresh samples from ADC0 and ADC1, for example, will actually have a time difference of  1/2400 = 0.42ms, which corresponds to (50*360)/2400 = 7.5 degrees in a 50Hz mains environment. In addition, current transformers in the analogue front end may typically contribute up to six degrees of additional phase lag. Phase distortions are calibrated using linear interpolation, as follows:

    Calibrated = x[n-1] + CalibCoefficient * ( x[n] - x[n-1] )

Note that linear interpolation is the same as a fixed time delay. This means that higher frequency componentes will not be adjusted correctly. Typically, though, not enough energy is present in the higher frequency components to cause this to degrade accuracy below acceptable levels.

Also note that the higher the sampling rate, the lower is the calibration range in degrees. If the sampling rate is too high, then the linear interpolation as such can not compensate for the phase lag of some DC immuned current transformers. Such transformers can have a phase lag in excess of six degrees.

[Source: AVR465.c example source file by Atmel Corporation to accompany application note AVR465: Single-Phase Power/Energy Meter with Tamper Detection.]
 

calypso_rae's picture

Re: PHASECAL and Serial Statements

Jörg: Thanks for the support, great to have you on board. 

very good point. This has also puzzled me for a while. Why extrapolate when interpolation would also be possible?

I think it's because the algorithm doesn't need to be changed, only the 'how far ahead?' value for the prediction.  A one-size-fits all algorithm must be easier to keep control of than several ones with subtly different timings.  As we're all trying to do a similar task, with similar equiment, it may be that a better arrangement can be derived which will suit everyone's setup better.

As shown in the piece that I posted yesterday on this thread, my hardware needs a PHASECAL value of around 2.5.  I feel sure that it will be in my best interests to change my code around so that the required value lies within the 0 - 1 range - hence PHASECAL can use interpolation rather than prediction.

But first, I need to be sure which voltage sensor I will be using for the lifetime of my system.  From Robert's excellent report on the Mascot AC/AC adaptor, it seems likely that a pair of lightly loaded adaptors wired in series (120V each), may give much improved results.  Before hacking my code around, I intend to put this idea to the test.  Watch this space ...

Robert: Try exchanging these two lines in calcVI( ) and see what value you need for PHASECAL

As I see it, the value of 2.5 shows that the current in my system is approximately 1.5 samples in advance of the voltage.  At present, with measurements being taken in the order V then I, the predicted voltage is required immediately that the current sample is available.  1.5 samples ahead of this point is approximately when the voltage sample after next is due,

If the samples were instead to be taken in the order I then V, there would then be a delay of around half a loop before the predicted voltage was required.  I feel sure that the PHASECAL value for my system would then fall to around 2 from its present value of 2.5.  I'll give it a try and let you know.

 

calypso_rae's picture

Re: PHASECAL and Serial Statements

Change of prediction:

With PHASECAL = 2.5, as my system appears to need now, I think that the I waveform is one sample ahead of the V.  This is because, when the voltage prediction is needed, the most recent voltage sample (V0) is already half a loop's worth old.  At that moment, we're at 1.5 on the PHASECAL scale.  PC = 2.5 is another full loop later, just at the time when the next sampleI is due.

When sampleI is taken before sampleV, two effects will come into play:

Firstly, because the calculation can't take place until the sampleV is available, sampleI has to wait around for half a loop.  That delay will reduce the prediction's 'length' by half a loop's worth.  Secondly, because the sampleV is brand new when the calculation is done, rather than half a loop old, PHASECAL doesn't have to base its prediction from a reference point in the past.  So that's another half loop of reduction.

Taken together, I think that changing the sample order as you've suggested will bring the required value of PHASECAL down to 1.5, which looks much more reasonable.  And if halving the voltage on the voltage adapter can reduce the amount of phase-advance that is introduced, then we may be onto a winner!

 

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

calypso_rae

Yup, when I measured the phase angles of both Mascot adapter and YHDC c.t, I realised that if the statement order were to be reversed, the correction required could be almost none. I did test it and it was indeed the case. But I didn't suggest it because of the confusion I thought it would cause (at that time, there was huge debate because nobody even knew the c.t. ratio!).

(The trick, in case you hadn't rumbled me, is to choose the order so that as close as possible the phase shift of one transformer is equal to the phase shift of the other plus the reading & conversion time for one input. So zero phase shift in the v.t. isn't necessarily the best target - it depends on how bad your c.t. is. Or vice versa).

calypso_rae's picture

Re: PHASECAL and Serial Statements

RW: As you have painstakingly explained to me in the past, there are only two activities of timing significance per measurement loop, these being the taking of the voltage and current samples.  If the current is in advance of the voltage, it makes sense to sample the current first because the voltage sample is then bang up to date when the power calculation is done, half a loop later.  The algorithm then doesn't have to predict so far ahead.

Anyway, how was my prediction? i.e. that Config A -> B would be -1.   It looks to be about right, but here are the results:

Config A:  240V chassis transformer as Vsensor, V sample first;  best value of PHASECAL = 2.8 or maybe 3

Config B:  240V mains transformer as Vsensor, I sample first;   best value of PHASECAL = 2.0

Config C:  two 'telecom' adapters in series, 120V each, I sample first;  best PHASECAL value = 1.8

Config D: a single 240V 'telecom' adapter, I sample first;   best PHASECAL value = 0.8

Putting two adapters in series did not achieve the desired effect.  That set of L-diagrams looked odd, rather like a triple figure of 8.  In terms of reducing PHASECAL, Config D was by far the best, and my rig spent the latter end of the day diverting energy on this basis, seemingly just as before.

With a properly set up system, I was hopeful that meter pulses would appear every 3600J regardless of the load size.  Sadly, the non-linearity still seems to be there.  Above 1kW load, the system appears to be pretty linear, but tails off significantly with smaller loads.  It appears to be around 5% less sensitive at 100W than at 1000W.  The leakage with no current flowing is around half a Watt.

Data files attached for anyone who likes watching the eyes open and close ;-)

Robert Wall's picture

Re: PHASECAL and Serial Statements

What do you mean by non-linearity? You say at 100 W it is 5% less sensitive. What does that 100 W represent: generated, absorbed or nett exported power?

I'm trying to figure out where a non-linearity like that might creep in. If it was a small d.c offset in the c.t. input that wasn't corrected and in the correct sense, it could appear less sensitive. I can't help thinking it might alternatively be a variable phase shift in the c.t., because the phase error in that is current-dependent. It rises as current falls ( by 1° from 40 A to 3 A), but I don't have any figures relevant to you - I stopped my tests at 62R burden and 3 A primary current.

Have you tried to measure PHASECAL at different currents? What happens when you try to establish PHASECAL at a current equivalent to 100 W?

calypso_rae's picture

Re: PHASECAL and Serial Statements

Non-linearity.  The Mk2 code that I'm running has the ability to record meter events.  At each pulse, it displays the energy status as recorded by the system.  Because of its upper and lower limits, the main energy bucket is no good for this purpose so I've added a parallel one without any limits).  When the house is drawing power from the grid, I expect to see meter pulses occurring at intervals of 3600J. 

With POWERCAL set to get 3600J per pulse for a 2kW load, I find that the 'energy per pulse' figure remains constant down to around 1kW but than starts to increase.  With a net import of just 100W or so (meter pulses less frequent) the 'energy change per pulse' value invariably climbs up towards towards the 4000 mark.  This is not due to leakage in my system as such, because it records no more than 0.5W when the CT is around a mains cable which has no current flowing.

Unfortunately, it's not possible to analyse the performance of the meter when the house is exporting.  The LED is just 'on', regardless of how many units of precious PV energy are slipping away.  My hope is that, if the system can record net power flow accurately during periods of net import, then the same system will produce accurate results when exporting (hopefully as little as possible!)

If the sensitivity of the system is non-linear, it's difficult to see how this could be accomodated.  One approach might be to gradually bias the system towards export, but then pull back a bit every time that a meter pulse is seen.  One pulse every minute or so would be a small price to pay (2p per day maybe) for knowing that the system really was utilising every last Joule of available PV. 

Robert Wall's picture

Re: PHASECAL and Serial Statements

I think we have to assume that the tariff meter is correct. I can't see that the code itself has any non-linearity in it, either by accident or design, so it has to be the transducers or the conversion. Somewhere between the actual current and voltage; and the numbers that the code uses; is where the problem must lie.

I can think of two possibilities (all the rest have to be linear!):

If you have pickup from the mains voltage into the current input, then at low power it could become significant. The effect would be lop-sided, it could even make a small power reverse its sign to change from generation to export, or vice versa. Unclipping the c.t. would remove this pick-up too, so reading 1 W with the c.t. removed from the cable doesn't rule this out. But it does seem to rule out pick-up elsewhere. This is possibility no.1. You can test this by putting the c.t. on the neutral instead.

We know the c.t has a phase shift that varies with current. That's possibility no.2. Unfortunately, you are looking for an error of around 10%, and I can't explain all of that with this theory.

I'll carry on thinking about this.

calypso_rae's picture

Re: PHASECAL and Serial Statements

Robert, I share your conviction that the tarrif-meter and the code itself can be eliminated from our enquiries.  In debug mode, with floating point maths throughout, my code is linear to the Nth degree.  Having dissected the stored waveform into individual samples for both V and I, and then reconstructed all the power contributions back together again, the results is identical to what I started with.  The single LP filter (which you kindly suggested that I might wish to try) has zero effect on the profile of either waveform.  It's rather like passing through a Star Trek transporter; one's bits are somehow sent flying out into the cosmos, but they all manage to come back together perfectly!)

In an AC environment, any form of wound component must be vulnerable to interferance.  As will any cables which carry miniscule voltages, such as the CT's cable.  I generally put the CT around the neutral wire, if only because it's a prettier colour.  Bring back the red one I say!

Minimal leakage is seen when my CT is clipped onto an extension lead where the conductors have been separated.  When clipped around either the Neutral or the Live cables near the meter, the only way to know how much current is flowing is by monitoring the LED.  That's what I've been doing, and it appears that my system is not entirely linear.

I feel sure that other correspondents will have investigated the linearity of their own OEM systems by now, and will soon provide us with the benefit of their findings ...

Series530's picture

Re: PHASECAL and Serial Statements

Undersampling ?

 

Under sampling and reconstruction...

I may be completely off base with what is needed here but I thought I would offer this thought:

If one of the issues is the phase delay introduced by sensing the CT and the VT separately and both are limited by the sampling rate of the ADC, could the system be set up such that the incoming waveforms are under sampled and then reconstructed? This gives a lot more phase resolution following a bit more maths.

I dont know how much timing control there is in the arduino (I will have a better idea soon having ordered all of the components) but, if it is possible, either I or V inputs could be sampled with a deterministic phase delay (say 10ms) and a deterministic sampling rate (non integer number of samples per mains cycle)  and each I and V input then sampled over several power line cycles simulaneously? Provided the acqusition time of the waveform isn't huge (just a few power line cycles rather than many) the waveforms should be pretty repetitive and the phase resolution then becomes a function of undersampling and we are no longer hampered by the sampling rate of the arduino ADC.

This may be happening as the sampling rate may not be properly locked to the mains frequency given that the processor is off doing other things (like serial printing). There is a subtle difference as, I think at least, what is being done at the moment is a measurement on a single shot capture rather than an undersampled reconstruction.

Remove the ADC sampling offsets and what is left is the errors due to the rest of the system and these can then be characterised separately.

Robert Wall's picture

Re: PHASECAL and Serial Statements

I've just thrown some numbers at a spreadsheet, and varying the starting point by up to one sample's worth (with 52 samples per cycle - about the norm), it makes 0.064 V difference (240 V to 240.064 V) to the rms voltage calculated over 1 cycle. OK, I appreciate that I haven't done the sum for power, and over a range of currents, and that we might not always get the same number of samples (although we do know how many) but it doesn't look hopeful for explaining a 10% error.

With POWERCAL set to get 3600J per pulse for a 2kW load, I find that the 'energy per pulse' figure remains constant down to around 1kW but than starts to increase.  With a net import of just 100W or so (meter pulses less frequent) the 'energy change per pulse' value invariably climbs up towards towards the 4000 mark."

This seems to say that we're looking for an error that increases to about 10%, apparently non-linerarly, as energy decreases, but which isn't there when the c.t. is not around the cable.

Calypso_rae: I'm just wondering whether the tariff meter is hitting 'anti-creep' and under-recording when you are almost balancing to give a low nett import?  If so,  then it's another a mechanism in the tariff meter that we don't fully understand yet.

[ If you detect grasping at straws - - you're right! ]

calypso_rae's picture

Re: PHASECAL and Serial Statements

I doubt whether 'anti-creep' would be affecting any measurements that I've made.  The change in sensitivity between consumption rates of 100W and 1000W can be detected immediately and seems very predictable. 

To shed more light on the meter's operation, I ran some tests yesterday but haven't looked at the results file in detail yet.  With 1kW of surplus PV, I repeatedly turned a 3kW kettle on and off while recording meter events and energy levels.  The logic inside the meter may well be more complex than I'd previously thought ...

stuart's picture

Re: PHASECAL and Serial Statements

Robin, when I get chance to test out your code, I'll put my AC clamp meter around the mains tails and see if the current levels drop to near zero - do you have anything similar you could try ?

Something like this...

http://uk.rs-online.com/web/p/clampmeters/0112752/

I've read a couple of electric meter manuals (boring!) and it seems the anticreep kicks in around the 10-12W area over a certain (unknown) period of time - once in this zone the meter stops recording unless the load ramps up over the 10-12W range.

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

What is creep? The concept comes from the induction watt-hour meter where if the magnets were not set up correctly, the meter would creep even when only the voltage coil was energised.

I would have assumed it was a very small constant current, such as you would get from capacitance between line and neutral, or dampness( ! ). But it is always possible that the meter is seeing accurately balanced 'trampolining' (i.e. a very low average current which is made up of a low and long export current backed off by a large short pulse of import) as a 'creep' current that ought to be ignored. 

I think that's just another feature of digital meters that we need to ponder over.

N.B. Anti-creep is usually defined as a current (Starting Current), and I think it's a bit less than the figure you give (for obvious reasons, because you could light an energy-saving lamp for free, and they'll never allow that!). It is specified in the standard as 0.4% of the base current, but that's not always given (it is NOT the maximum current). 20mA seems a common figure (=4.8 W) (40 mA for a Siemens S2AS-100) for Starting Current.

However, the Magnetic Card meter recently posted (I forget by whom) specifically states "Anti creep occurs if an average power of 12.5 watts (+-20%) or less is detected for a period of 4 minutes and 48 seconds.  Activation of anti-creep is indicated by the red LED being continuously lit. This function is reset as soon as the average power over 4 minutes and 48 seconds exceeds 12.5 watts (+-20%); the LED then returns to pulsing as normal."  But as the starting current for this meter is 100 mA, it may not be typical of all meters.

calypso_rae's picture

Re: PHASECAL and Serial Statements

When starting out on this lark, I bought a clamp-style current meter from Maplin for around £15.  A seriously useful piece of test kit - or so I thought.  However, when compared with the measurements of current which are so easy to make using an Arduino, the results are rubbish!  OK, it can probably tell you whether the kettle is on or off, but it could never distinguish between the currents taken by 40W, 60W and 100W bulbs as my test rig has repeatedly done. 

The only way to know what's going on at the meter is via its LED.  The standard inport meter provides accurate 3600J markers in one direction of energy flow.  If everything is linear, one would expect a measurement system to behave the same in either direction.  Fitting  an export meter would allow the system to be checked in both directions.

stuart's picture

Re: PHASECAL and Serial Statements

Have you tried reading out the meter over the infrared port ?

Think they output more granular level of data than the display shows (more decimal places)

Robert Wall's picture

Re: PHASECAL and Serial Statements

Call me a measurement junkie, but I'd seriously doubt any test "instrument" at that sort of price. As you say, good for a general indication but not for serious measurement. I think my multimeter (also from Maplin but no longer available) cost about £40 and is about as good as they come in that price range. To get a marked improvement in accuracy especially on the a.c. ranges (i.e a factor of 4 - 3% to 0.7%) you need to spend about 10 times that money; and if you want better than that (0.3%) you are looking at close on £1000.

calypso_rae's picture

Re: PHASECAL and Serial Statements

Stuart: No, I've not tried to use the infra-red port.  Even if I knew the protocol, I'm not sure that this would work; I think it's more for diagnostic purposes.

As others have mentioned, the 5235 manual does talk about an anti-creep mode.

Below starting current, the meter enters into an anti-creep mode.  In this
state the metrology LED is permanently lit and the registers do not
increment.  The LED remains lit until the meter current is increased in a
forward direction beyond the starting current. The starting current is shown
in the technical summary.

Current (Base) Direct connection  Ib   5A, 10A, or 20A
Current (Max) Imax 40A, 60A, 80A or 100A
Starting Current (IEC) 0.4% of Ib

When my Mk2 controller is active and working correctly, the net flow through the meter should be zero.  In this state, it is probably entirely reasonable that the meter should go into "anti-creep" mode.  It may therefore be the case that what I have been interpreting as "export" is actually "anti-creep". 

stuart's picture

Re: PHASECAL and Serial Statements

Interestingly, the manual also says...

Export:

"Alternately the register is held in memory and can be read from the meter via the IEC 1107 port"

http://www.solarinverters.com.au/files/users_manuals/usermanual-ahmzqq.pdf

So the exported energy is kept internally in the meter (even if not displayed) and can be read through the port.

The interface is a standard, circuit diagram here...

http://www.elektor.com/magazines/2002/march/iec1107-electricity-meter-in...

 

On the PHASECAL stuff, does this mean that you could write software to auto calibrate the value - assuming that it was a totally resistive load during the calibration phase ?

calypso_rae's picture

Re: PHASECAL and Serial Statements

Stuart: So the exported energy is kept internally in the meter (even if not displayed) and can be read through the port.

Well spotted, thanks for that insight, Stuart

On the PHASECAL stuff, does this mean that you could write software to auto calibrate the value - assuming that it was a totally resistive load during the calibration phase ?

Yes, that sounds entirely feasible to me.  I have a version of my Phase Diagram Tool which runs several times using a different value of PHASECAL each time.  By scanning up and down the Serial window, the best value can be easily seen from the 'eye' diagrams.  Once set up up correctly, the value should never need to change, so I'm not sure whether an auto cal feature would be beneficial.

Nudging the algorithm whenever anything happens at the meter's LED sounds a great idea.  The virtual meter would then be linked to the physical one rather than operating in glorious isolation.

calypso_rae's picture

Re: PHASECAL and Serial Statements

In the circuit schematic for my Mk2 PV Controller, I've shown a 150R burden resistor.  This value of burden gives a decent sized signal at the Arduino for a 3kW load and is the setup that has been reliably working in our garage for the last few weeks.  We've had 4kWh so far today and the water is fully up to temperature with the stat off.  All that lovely power which is now being being wasted ....

However, it has now become appararent that CTs don't like working at such high output levels.  Rather than using a high value of burden to obtain a high signal, it is much better to use a low value of burden and then boost the amplitude with an op amp buffer that has some gain.

It has also become apparent to me that the standard YHDC CT is not really a quality component.  Even the tiniest of air gaps ruins the readings.  With only plastic springs to keep if shut, the continuity of the ferrite core is problematic to say the least.  Yesterday, I invested in a different type of CT, the smallest variant in the Magnelabs range via Rapid Online.  (This variant now claims to be 'discontinued', but there are many others; the 50A one should be fine)

The Magnelab CT has 'lapped' joints in its metallwork.  When clipped together, the continuity of the flux-carrying core is as good as it can be for a non-invasive design.

Four results files are attached, all with the same format.  Two files relate to the standard YHDC-30 CT; one with a high value of burden (150R), the other with a low burden (39R) and a x3 buffer.  The other two relate to the Magnelabs CT; again, one has a high value of burden (820R), the other has a low burden (220R) and a x3 buffer.  The absolute sensitivies of the CTs are different hence the different values of burden that I've used.  The size of the signal  presented to the Arduino is similar in all cases.

To quickly compare between these four configurations, look at the end of each file.  There you will find the 'eye' diagrams for each setup with a 3kW load.  The worst configuration by far is the one that I've been using to date.  

[Update:  If only measuring "real power", which is what a domestic electricity meter does, the results are hardly affected by the quality of the 'eye diagram' .  Using 150R with the standard 30A YHDC CT (from which the internal burden has been removed) seems fine for all practical purposes).  Other builders have successfully used a smaller burden and boosted the output via a buffer stage, but the difference in performance appears to be minimal.]

 

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

Picking up on this: "Rather than using a high value of burden to obtain a high signal, it is much better to use a low value of burden and then boost the amplitude with an op amp buffer that has some gain."

Using a higher value burden on a current transformer has exactly the same effect as using a lower resistance load on a voltage transformer - you overload the transformer. 

Although they operate on the same fundamental principles, current transformers are the dual of voltage transformers.

Voltage transformer Current transformer
Happy on open circuit Happy on short circuit
Destroyed on short circuit by over-current Destroyed on open-circuit by over-voltage
Most turns (usually) on the primary winding Most turns on the secondary winding
Steps down voltage proportional to turns ratio Steps down current proportional to turns ratio
Steps up current proportional to turns ratio Steps up voltage proportional to turns ratio
Secondary voltage is defined by primary voltage Secondary current is defined by primary current
Primary current is defined by secondary current Primary voltage is defined by secondary voltage
Power transferred is limited by VA rating Power transferred is limited by VA rating

N.B.

  1. The primary voltage for a current transformer is the voltage drop in the main conductor measured from one side of the transformer to the other. For the standard 100 A : 50 mA c.t. with 1 V appearing across the burden, the primary voltage is 0.5 mV.
  2. All the above are approximations that neglect losses.

 

stuart's picture

Re: PHASECAL and Serial Statements

calypso_rae's picture

Re: PHASECAL and Serial Statements

Stuart, that circuit appears to be for getting DC from AC.  By removing the diodes, It would appear to provide a buffered source of AC which is what we would need. 

The x3 buffer that I mentioned yesterday is essentially doing the same job as the pair that they're using.  The first of their two buffers, however, seems unnecessary; it's not doing anything of use.  The second one (in my case, x3) is fine by itself and does not load the CT at all.  I've used an LM358, with R2 = 68K, R1 = 33K as shown here .  Unfortunately, to cover the full range of the Arduino's ADC,  this device needs a supply voltage greater than 5V; I've provided a +9V supply.

Sorry, the final document is way beyond my comprehension.  All I know is that I want my measurement system to measure a resistive load as a resistive load.  Any phase-shifts must therefore be accounted for and calibrated out.  Forcing a CT above its intended voltage appears to cause phase-shift.  This unwanted effect is level-dependent, or non-linear.  Bad News.

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

stuart

You don't actually want a d.c. output. The whole point of taking voltage and current samples and multiplying them together is to get an accurate measure of power. If you take a rectified average for (presumably both) voltage and current, you have to calibrate it assuming a sinusoidal waveform (or at least some defined waveform) and then it's wrong by varying amounts for every other wave shape.
Not what we want.

calypso_rae

"Forcing a CT above its intended voltage appears to cause phase-shift.  This unwanted effect is level-dependent, or non-linear.  Bad News."

Yup. You will get a much more accurate waveform by keeping the burden resistor as small as possible (i.e. more lightly loading the c.t.). Some degree of distortion and phase shift is nevertheless inevitable with wound components.

kllsamui's picture

Re: PHASECAL and Serial Statements

hi calypso_rae

in openenergymonitor.org/emon/node/796

i described a very bad effect by a high burden resistor (and a too high current).

And also indicated by the need to use a PHASECAL > 3

 

but if the point is to read low amps with a " too big" CT

there is still the option to wind the prim. wire ( example 10 times )  through the CT.

From the photo i see no space problem doing that.

And much more easy as any opamp circuit.

But anyway you loose the upper range.

 

Its difficult to find a nice graph like that for a CT, where you find measuring range for diff. burden resistors.

burden

Robert Wall's picture

Re: PHASECAL and Serial Statements

kllsamui

The smallest size of cable generally used in the UK upstream of the main switch is 16 mm2.  It is only possible to pass 1 turn of that cable through an aperture that is 12 mm x 12 mm.

We know the properties of the YHDC SCT-013-000, and there is good reason to believe the -030 is the same core and secondary winding with a burden resistor added internally.

I have not measured the Magnelab c.t. which Calypso_rae is now using.

calypso_rae's picture

Re: PHASECAL and Serial Statements

stuart: Some degree of distortion and phase shift is nevertheless inevitable with wound components.

A constant amount of phase-shift is fine because it can be easily calibrated out using the PHASECAL technique.  The problem arises when the phase-shift becomes non-linear.  Phase shift from CTs appears to be minimal (<2deg) when the output level is small, but  increases quite dramatically when the output voltage exceeds a certain level.  The maximum output signal that a YHDC-type CT should be asked to supply appears to be around 1V p-t-p. 

When allocating power, it is important that the measurement system is linear.  Let's say that 300W of spare PV power is available.  With a 3kW immersion, the triac will be on for approximately one cycle in every ten.  For the majority of cycles, when the triac is off, 300W of surplus power will be slipping out to the grid; that's 1.2A rms or thereabouts.  But for every tenth cycle, when the triac is on, 2700W will be entering at the supply point; that's around 11A rms.  Providing that the measurement system is linear over this range of currents, then all will be fine.  But if the amount of phase-shift varies with amplitude, then the ratio of the powers measured during 'on' and 'off' cycles will not be correct, and the system will drift relative to the supply meter. 

Because the mains voltage doesn't change much, one might expect that any phase shift from the voltage sensor would be fairly constant.  Robert's report, however, shows that the Mascot AC/AC adapter is surprisingly sensitive to mains voltages that are higher than normal.

 

 

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

"Robert's report, however, shows that the Mascot AC/AC adapter is surprisingly sensitive to mains voltages that are higher than normal."

My favourite explanation for that is they're designed for the US/Continental market where the supply is nominally 220-230 V, and ours remains centred on 240 V. So even at our nominal centre voltage, they're already being over-run; and as we know, saturation is highly non-linear.

But for that to have an effect, you need to have a weak supply so that the dip on the cycle when you fire the triac can account for at least part of the discrepancy. Have you tried to measure that?

calypso_rae's picture

Re: PHASECAL and Serial Statements

Robert, the tool that I use to display waveforms is a 1-shot device.  After allowing the filters to settle, it identifies a particular cycle and records all V & I samples taken during that cycle.  It then moves into a display mode and waits for further instructions from the user. 

Because of the time spent outputting the data, this is a stand-alone tool; it is not part of the standard sketch which has to run continuously.  It would be entirely feasible to pre-switch on the triac just for the cycle that is being recorded; this would essentially be testing the impedance of our mains supply.  Our supply does appear to be 'weak', Henry the vacuum provides a good indication of this.  While he is whirring away in the background, if I apply a 2kW load on a separate ring-main, Henry's pitch can be heard to drop.  Similarly, when a 3kW kettle or 8kW shower are turned on, the lights always dim slightly.  This doesn't seem to cause a problem, it's just a feature of the house.  Aren't all houses like this?

For a constant load, it may be interesting to see how the V & I samples are affected when additional power is drawn by household appliances.  This test is probably best done after hours when there's no PV.   Otherwise there would be too many variables.

Robert Wall's picture

Re: PHASECAL and Serial Statements

"Aren't all houses like this?"

It shouldn't be the house - on its own at least. I've just done the test and my 3 kW immersion heater drops the mains from 245 V to 243 V (by multimeter, not emonTx, so only 3 digits resolution!), which makes the supply impedance 0.16 Ohms or about 370 kVA fault level (with deplorable uncertainty in the measurement - I must try harder!).

Put it another way, I couldn't see a dip in the lights when I switched the immersion heater on and off.

calypso_rae's picture

Re: PHASECAL and Serial Statements

A neat test, now why didn't I think of doing that ???

Our 3kW kettle also appears to drop the house voltage by around 2V.  On the same ringmain, however, the voltage drop is about twice as much, more like 4V.  That is the situation in which the vacuum cleaner's pitch can be heard to change.  A 4V drop in voltage is likely to result in a 2-3% reduction of power.

Actually, when I notice the lights dim, it's generally when the 8kW shower is turned on rather than just the kettle. 

calypso_rae's picture

Re: PHASECAL and Serial Statements

If anyone is interested in finding out what is the best value of PHASECAL for their hardware, here is a tool that should do the job.  It needs the Serial window to be open, otherwise nothing will happen.  When requested, you enter the min and max values for PHASECAL and the amount that it should be incremented per run.  Then just sit back and watch it doing its thing.

For the sketch to work as intended, the voltage and current sensors need to be working, and some current needs to be flowing.  I've attached the results file for a 750W resistive load.  Looking st this file, the optimal value for the hardware that I'm using appears to be around 1.5.  That's when the power factor is closest to one.

Another way of checking the effects of PHASECAL is with the 'eye diagram' tool that I posted some weeks ago.  Using that sketch, I've attached the results file for a similar range of values.  Given the limited resolution  of the displays, the optimal value for PHASECAL is not clear to see.  What is fairly evident, however, is the distortion that extreme values of PHASECAL can cause to the voltage waveform.

PHASECAL does not appear in my original Mk2 PV Router sketch at http://openenergymonitor.org/emon/node/841, but it is included in the cut-down version that I've posted today at http://openenergymonitor.org/emon/node/841#comment-5925

All feedback welcome.

 

 

stuart's picture

Re: PHASECAL and Serial Statements

calypso_rae on Mon, 27/08/2012 - 20:06. 

Thanks for the sketch Robin, I've tried this out using a low pass filter to shift the phase of the current signals to match the voltage.

Looks like a winner, a PHASECAL value of around 0.8 seems to work best in my circuit.

 

The initial value of PHASECAL is 0.25
real power = 16241.45, apparent power = 16319.47, power factor = 0.99522
real power = 16298.89, apparent power = 16377.40, power factor = 0.99521
real power = 16303.07, apparent power = 16381.76, power factor = 0.99520
real power = 16292.60, apparent power = 16371.40, power factor = 0.99519
PHASECAL is now 0.30
real power = 16298.74, apparent power = 16369.23, power factor = 0.99569
real power = 16291.82, apparent power = 16363.46, power factor = 0.99562
real power = 16283.92, apparent power = 16355.43, power factor = 0.99563
real power = 16234.58, apparent power = 16306.18, power factor = 0.99561
real power = 16292.06, apparent power = 16363.91, power factor = 0.99561
PHASECAL is now 0.35
real power = 16293.87, apparent power = 16357.90, power factor = 0.99609
real power = 16302.49, apparent power = 16367.51, power factor = 0.99603
real power = 16342.65, apparent power = 16407.69, power factor = 0.99604
real power = 16344.29, apparent power = 16409.45, power factor = 0.99603
real power = 16344.48, apparent power = 16409.66, power factor = 0.99603
PHASECAL is now 0.40
real power = 16355.08, apparent power = 16412.75, power factor = 0.99649
real power = 16368.39, apparent power = 16427.92, power factor = 0.99638
real power = 16359.47, apparent power = 16418.61, power factor = 0.99640
real power = 16356.30, apparent power = 16415.46, power factor = 0.99640
real power = 16355.65, apparent power = 16414.74, power factor = 0.99640
PHASECAL is now 0.45
real power = 16386.81, apparent power = 16438.58, power factor = 0.99685
real power = 16372.96, apparent power = 16426.44, power factor = 0.99674
real power = 16378.08, apparent power = 16431.83, power factor = 0.99673
real power = 16365.51, apparent power = 16419.31, power factor = 0.99672
real power = 16340.32, apparent power = 16394.61, power factor = 0.99669
PHASECAL is now 0.50
real power = 16362.72, apparent power = 16409.66, power factor = 0.99714
real power = 16354.38, apparent power = 16403.41, power factor = 0.99701
real power = 16355.29, apparent power = 16404.12, power factor = 0.99702
real power = 16341.52, apparent power = 16390.47, power factor = 0.99701
real power = 16343.86, apparent power = 16392.81, power factor = 0.99701
PHASECAL is now 0.55
real power = 16346.63, apparent power = 16389.05, power factor = 0.99741
real power = 16342.11, apparent power = 16386.93, power factor = 0.99727
real power = 16336.18, apparent power = 16381.06, power factor = 0.99726
real power = 16341.98, apparent power = 16386.42, power factor = 0.99729
real power = 16330.65, apparent power = 16374.93, power factor = 0.99730
PHASECAL is now 0.60
real power = 16304.29, apparent power = 16342.98, power factor = 0.99763
real power = 16308.64, apparent power = 16349.87, power factor = 0.99748
real power = 16310.90, apparent power = 16352.08, power factor = 0.99748
real power = 16303.64, apparent power = 16344.88, power factor = 0.99748
real power = 16306.83, apparent power = 16348.01, power factor = 0.99748
PHASECAL is now 0.65
real power = 16322.13, apparent power = 16358.38, power factor = 0.99778
real power = 16318.12, apparent power = 16356.70, power factor = 0.99764
real power = 16315.22, apparent power = 16353.80, power factor = 0.99764
real power = 16322.26, apparent power = 16360.43, power factor = 0.99767
real power = 16312.48, apparent power = 16350.86, power factor = 0.99765
PHASECAL is now 0.70
real power = 16325.61, apparent power = 16359.38, power factor = 0.99794
real power = 16349.14, apparent power = 16385.85, power factor = 0.99776
real power = 16381.06, apparent power = 16418.47, power factor = 0.99772
real power = 16349.04, apparent power = 16385.83, power factor = 0.99776
real power = 16320.15, apparent power = 16356.44, power factor = 0.99778
PHASECAL is now 0.75
real power = 16510.65, apparent power = 16543.49, power factor = 0.99801
real power = 16496.20, apparent power = 16531.71, power factor = 0.99785
real power = 16504.86, apparent power = 16540.29, power factor = 0.99786
real power = 16506.81, apparent power = 16542.36, power factor = 0.99785
real power = 16492.92, apparent power = 16528.63, power factor = 0.99784
PHASECAL is now 0.80
real power = 16514.72, apparent power = 16546.32, power factor = 0.99809
real power = 16519.68, apparent power = 16555.16, power factor = 0.99786
real power = 16528.38, apparent power = 16563.46, power factor = 0.99788
real power = 16530.77, apparent power = 16565.62, power factor = 0.99790
real power = 16528.87, apparent power = 16563.59, power factor = 0.99790
PHASECAL is now 0.85
real power = 16510.61, apparent power = 16542.81, power factor = 0.99805
real power = 16507.60, apparent power = 16542.69, power factor = 0.99788
real power = 16501.31, apparent power = 16536.90, power factor = 0.99785
real power = 16513.56, apparent power = 16548.48, power factor = 0.99789
real power = 16533.04, apparent power = 16568.13, power factor = 0.99788
PHASECAL is now 0.90
real power = 16541.72, apparent power = 16574.88, power factor = 0.99800
real power = 16530.82, apparent power = 16566.68, power factor = 0.99784
real power = 16555.09, apparent power = 16590.97, power factor = 0.99784
real power = 16583.31, apparent power = 16619.74, power factor = 0.99781
real power = 16593.59, apparent power = 16629.83, power factor = 0.99782
PHASECAL is now 0.95
real power = 16603.18, apparent power = 16637.91, power factor = 0.99791
real power = 16559.16, apparent power = 16596.84, power factor = 0.99773
real power = 16548.24, apparent power = 16585.75, power factor = 0.99774
real power = 16562.92, apparent power = 16600.62, power factor = 0.99773
real power = 16567.91, apparent power = 16605.44, power factor = 0.99774
PHASECAL is now 1.00
real power = 16579.68, apparent power = 16616.04, power factor = 0.99781
real power = 16568.13, apparent power = 16607.89, power factor = 0.99761
real power = 16587.74, apparent power = 16627.81, power factor = 0.99759
real power = 16554.26, apparent power = 16594.22, power factor = 0.99759
real power = 16577.06, apparent power = 16616.61, power factor = 0.99762
End of run, please restart to repeat


 

calypso_rae's picture

Re: PHASECAL and Serial Statements

Yes, that sounds a good combination. 

Include an analogue filter so as to get the optimal value of PHASECAL to lie within the range 0 - 1, and then run the tool to find exactly the right value.  The code in the tool needs to match that in the final application; measuring V and I in different orders would defeat the object of the exercise.

calypso_rae's picture

Re: PHASECAL and Serial Statements

On second thoughts, wouldn't it better to store samples (V or I) until they can be combined without requiring PHASECAL to be  outside the range 0 to 1?  This approach would be guaranteed not to introduce any distortion, unlike with any kind of additional filter.

The phasecal algorithm already stores one sample (the previous voltage sample).  Storing addition samples would be a straightforward upgrade ... if it really matters, that is.  My results yesterday suggest that phase-shift errors have remarkably little effect on the system's ability to maintain the balance condition, which is all that really matters for this application.

stuart's picture

Re: PHASECAL and Serial Statements

But more of an effect if you try and mix reliable readings and the solar dump controller!

 

calypso_rae's picture

Re: PHASECAL and Serial Statements

Using a spreadsheet, I've been playing around with various ways that V & I waveforms can be sampled and processed.  I'm not sure whether anything of particular use has been discovered along the way, but the various graphs may be of general interest.  Each one is on a separate page/tab, so it's really easy to flick between the pages to see how things change.  These exhibits may be of interest to anyone who is considering phase-angle control, or who wants to understand PHASECAL in a simple hands-on way.

Sheet 1: 30 pairs of V&I sample pairs per cycle, both taken at the same time.  As expected, there is no residual drift at the end of the cycle, but there is some cumulative error as the cycle progresses.

Sheet 2: As for sheet 1 but with only 15 sample pairs per cycle.  As expected, there is more cumulative drift as the cycle progresses.

Sheet 3: As for sheet 2, but with the the I sample taken first and delayed until the V sample is available.  This is how the Arduino measures power.  Note that there is now a residual drift at the end of the cycle.  This is because the two waveforms have effectively been shifted in time.

Sheet 3a: As for sheet 3, but with only half the amplitude of current.  The residual drift at the end of the cycle is now halved.  This shows that the drift is proportional to the amount of energy that is present, so could be compensated for by POWERCAL. 

Sheet 4: As for Sheet 3, with the I sample being taken and delayed until the V sample is taken.  It is then multiplied by the average of the two most recent voltage samples.  This is effectively applying a PHASECAL of 0.5.  This re-aligns the two waveforms in time, but slightly reduces the amplitude of the voltage waveform.  Note that there is no longer any cyclic wobble in the cumulative error curve, just the residual drift.

Sheet 5: As for Sheet 3, but with a calculation being done as soon as a new sample is available.  Each sample is now used twice.  This causes the two waveforms to remain aligned in time, but causes havoc with the plotting facility.  Note that the cyclical variation of cumulative error has stayed away.  In this particular case, this simple technique has much the same effect as applying PHASECAL = 0.5.

Sheet 6:  As for Sheet 3, but with the current flow interrupted after 90 degrees.  As expected, the large cumulative error remains.  This would be Bad News if dumping power using phase-angle control.

Sheet 7: As for Sheet 5, but with the current flow interrupted after 90 degrees.  As expected, the small cumulative error remains.  This would be a much better situation if dumping power using phase-angle control.

Sheet 8:  Back to 30 sample pairs per cycle (as per Sheet 1) but with a one loop phase shift (I is advanced w.r.t. V).  We now see a negative residual drift because the Power Factor is less than unity.

Sheet 9:  As per Sheet 8, but with a PHASECAL of 2.  This realign the waveforms perfectly in time but not in amplitude.  Being outside the range of 0 to 1, POWERCAL introduces a positive gain.  We now see a net positive residual drift because the distorting effect of PHASECAL more than compensates for the reduction in amplitude caused by the Power Factor being less than unity.

Sheet 10:  As for Sheet 1 but with a two-loop phase shift (I is advanced w.r.t. V).  We now see a greater negative residual drift because the Power Factor is significantly less than unity.

Sheet 11:  Applying PHASECAL = 3 to realign the waveforms adds a large positive offset to the cumulative error.  Note that the graph has changed scale.  Although this additional gain can be compensated for by calibration, this is not a good way to treat the measured waveform.  With a voltage waveform that is not sinusoidal, the distortion can look even worse. 

Sheet 12:  The current waveform has the same amount of phase advance as in Sheer 10, but with only 15 sample pairs per cycle rather than 30.  The cumulative error curve is similar to before but lumpier on account of the reduced resolution.  The residual drift is still negative because the Power Factor is less than unity.

Sheet 13: The current waveform still has a similar amount of phase advance, but each calculation is now done as soon as a new sample is available.  This means that each sample is used twice, as per Sheet 5.  The variation of the cumulative error curve within the cycle is noticably reduced, which can only be good.
   Although the V and I graphs appear rather lumpy, this is just because of the way that have been plotted.  Double-using each sample may well be a useful technique, especially if the correct amount of PHASECAL is not known or is not being applied.
 

Tinbum's picture

Re: PHASECAL and Serial Statements

Hi, I'm new to this forum and don't have the knowledge that you do but have a couple of questions as I'm in the process of ordering everything.

The 9v supply for the CT - can that be taken from the voltage sensor supply via a suitable bridge rectifier and regulator.

I've ordered the CT (SCT-0750-050). How do I determine the best burden resistor as your CT had none within it and I can't see any details on the resistor already fitted in the SCT-0750-050

I like the anti flicker video and the possibility it brings to operating other equipment that isn't just a heating element.

Many years ago I had a problem with a high frequency flicker in a house I lived in. It occurred about 6am in the  morning and within a specific time frame. It was very fast and not noticeable to everyone but very annoying to me. It took a while for the DNO to realize there was a problem, having first just used some very basic equipment to monitor it, which i knew it wouldn't show on. To cut a long story short they couldn't find the problem in our small village but 6 months later they had the same problem in a much smaller village and the person investigating recognized a piece of equipment he recalled seeing at a house he'd visited in our village and put two and two together. If I recall it was a Triac controlled Range and it turned out to be a manufacturing problem. 

calypso_rae's picture

Re: PHASECAL and Serial Statements

Hi, and thanks for giving this thread a nudge :)

The CT is entirely passive, so doesn't need any power supply as such.  One of its ends is connected to a DC reference, that being a simple voltage divider across the Arduino's 5V rail.  I always buffer that reference and then use it for both sensors.  The standard approach is to have two separate (unbuffered) references.  This is how the emonTx hardware is configured.  Both approaches seem to go give very similar performance.

The burden resistor is a bit of a black art.  I generally use whatever value gives around a 3 or 4 Volt swing with a 3kW load.  This is undoubtedly using the CT outside its recommended range, but seems to give better results than when restricting it to the sub-1V range.  Other contributers have successfully boosted the CT's output but my attempts did not appear to give any improvement so I've not pursued this route. 

I'm pleased that you like the anti-flicker video.  Personally, a bit of flicker doesn't bother me, but I appreciate that there are published standards which ought to me maintained, particularly if a power diversion system is being built for other than DIY use or is of a particularly high rating.  The a/f algorithm is not mine as such, but I thought that it would be helpful for this feature to be included in my latest Mk2 version for completeness.

Tinbum's picture

Re: PHASECAL and Serial Statements

Hi, Thanks for the reply. sorry i should have made myself clearer.  The 9V supply was in reference to what you had said earlier in the thread Quote:

'The x3 buffer that I mentioned yesterday is essentially doing the same job as the pair that they're using.  The first of their two buffers, however, seems unnecessary; it's not doing anything of use.  The second one (in my case, x3) is fine by itself and does not load the CT at all.  I've used an LM358, with R2 = 68K, R1 = 33K as shown here .  Unfortunately, to cover the full range of the Arduino's ADC,  this device needs a supply voltage greater than 5V; I've provided a +9V supply.'

 

This was what i was looking at doing but is it not worthwhile? If it is then i think I've found the answer to my own question_ the 9v could come from the Vin pin.

 

The flicker I experienced was very annoying, It was constant and really really fast, I don't know what frequency but some people could see it and some couldn't. I now suffer from optical migraines (weird, until you know what they are!) and I could imagine that experiencing that again would probably set one off. I cant imagine what load it must have been but it must have been very large.

Robert Wall's picture

Re: PHASECAL and Serial Statements

"The burden resistor is a bit of a black art."

No it isn't! A current transformer is the dual of the much more common voltage transformer. Therefore you overload it by asking for too much voltage out of it (by increasing the burden resistor value). And when you overload it, it saturates and distorts the waveform. Simple. It's just that the VA rating of the miniature c.t's that we use isn't published, so it has to be determined by measurement..

calypso_rae's picture

Re: PHASECAL and Serial Statements

OK Robert, point taken.  The black art comes into play when deciding how best to configure the input circuit so as to give best overall performance. 

If possible, I would much prefer to operate my CT with a low-valued burden so that the voltage which is seen across that resistance is only small.  However, this means that only a small fraction of the useful input range of the ADC is being used.  Quantisation Distortion therefore becomes very significant at small levels of current.  A higher value of burden is good for increasing the voltage swing but is no doubt bad for the CT's performance.

New Year's resolution - I must try to get the terminology right!

rj017850's picture

Re: PHASECAL and Serial Statements

The pressure resistor is a bit of a dark art. I usually use whatever value gives around a 3 or 4 Voltage move with a 3kW fill. This is certainly using the CT outside its suggested variety, but seems to provide better outcomes than when reducing it to the sub-1V variety. Other contributers have efficiently enhanced the CT's outcome but my efforts did not appear to provide any enhancement so I've not followed this path. all best serials

calypso_rae's picture

Re: PHASECAL and Serial Statements

If "pressure resistor" is another term for the "burden", then I agree with your findings 100%.  Welcome to the forum!

9fingers's picture

Re: PHASECAL and Serial Statements

I'm tempted to try running the CT into a virtual earth amplifier (using the other half of the 358).

This should keep the CT in totally in current mode as the amplifier will not allow any voltage to develop accross the transformer secondary and the feed back resistor in the amplifier will allow what ever voltage swing is needed to give the ADC optimum resolution.

Diagram attached. The theory is that an ideal amplifier will allow no voltage difference between + and - inputs and the output voltage will adjust to try and achieve this. So the current through the resistor must equal the current through the transformer secondary.  so Vo = -I * R

Bob

Robert Wall's picture

Re: PHASECAL and Serial Statements

Are you going to follow it up with a driver circuit of some sort? The LM358 is only guaranteed to source 20 mA and sink 10 mA and that's with a 15 V supply.  According to me, that's not 15 A of primary current. And you might need to beef up your power supply too.

9fingers's picture

Re: PHASECAL and Serial Statements

I don't see the need. The coil shown is the secondary of a standard current transformer that Robin's design already uses.

I'm not sure of the turns ratio but we are talking of a few mA in the secondary for 15A on the primary so the LM358 is perfectly adequate.

 

Bob

 

PS I did not get an email prompt about the reply. Does that need to be set up somewhere please?

calypso_rae's picture

Re: PHASECAL and Serial Statements

When a thread to which I have already contributed is updated, I don't get an email prompt, but the number of "new" contributions is shown at the top of my "Track" view.  If I am sent a PM, I also get an email.  This arrangement works fine for me so I've never tried to change it.

I like the idea of keeping the CT in current-only mode and hope to try out your suggestion soon.  My main rig still uses its original breadboard with half of the Vref op amp unused, so it should be easy enough to make this change.  Whether it will ever work again is another matter ...

9fingers's picture

Re: PHASECAL and Serial Statements

Thanks Robin,

 

When you try it out, don't for get the phase inversion in the circuit. Possibly easiest to change the direction of the transformer on the incomer.

I suppose the best way to test the effect is to impose a load of 10-15amps and then run phasecal before and after the change.

 

Bob

Brian D's picture

Re: PHASECAL and Serial Statements

The I to V circuit that 9fingers has suggested looks like an excellent idea to me but the LM358 is output swing limited so is not a good choice of device. Something like the TS912N is pin compatible and is rail-to-rail.

A good article on I to V can be seen here. One problem I can think of is that the cheap jack plugs and sockets can momentarily go open circuit sometimes and that will probably kiss your front end goodbye. Some protection diodes inside the CT should be enough to fix this.

 

9fingers's picture

Re: PHASECAL and Serial Statements

Both very valid points Brian. I have to put my hand up to initially discussing the use of a VE amplifier as a concept and then thought maybe not everyone would know about such things and a quick diagram would help.

 

Bob

calypso_rae's picture

Re: PHASECAL and Serial Statements

My first dabble with the new CT connection scheme did not give promising results, not sure why.  Hope to have another go tomorrow. 

I was using a feedback resistor of 220R, but have no idea whether that's a sensible value for this circuit.

9fingers's picture

Re: PHASECAL and Serial Statements

Typically the resistor would be the same as the burden resistor and if the original burden is inside the CT, this needs to be removed. Also bear in mind Brian's comments.

Back to back diodes in the CT in place of the burden resistor for protection and an op amp suitable for rail to rail output.

Bob

calypso_rae's picture

Re: PHASECAL and Serial Statements

As the purpose of the op amp is to maintain both ends of the CT's output at the same potential, would there be any harm in leaving an internal burden in place?  It would only come into play when the op amp ran out of steam, which may be no bad thing. 

 

9fingers's picture

Re: PHASECAL and Serial Statements

Good point Robin.

Bob

Memo to self: Think about things a little deeper before posting - it might save some of those red face moments I've been getting recently.

calypso_rae's picture

Re: PHASECAL and Serial Statements

Think about things a little deeper before posting - it might save some of those red face moments I've been getting recently.

No problem, I'm sure we've all had that feeling. 

Some years ago, the Open University had an email feature whereby you could 'unsend' any message that you'd had second thoughts about.  A brilliant idea.  Unfortunately, it was less easy to get people to 'unread' what you had just unsent!

 

girishgrao's picture

Re: PHASECAL and Serial Statements

Hi

I have read with much interest all the research and development you have done on this project.  These posts seem to be about an year old and I wonder if you are still pursuing this project further.

Just wanted to ask if you have considered the following:

1. Use a standard metering IC from a supplier like Analog Devices.  A single phase metering IC with an SPI interface to a microcontroller would solve all your problems of measuring accuracy.  It would also give you the active power reading straightaway.  The MCU then only has to do some logical comparisons and operate the Triac suitably.

2. Use a standard toroidal metering CT rather than a clamp CT.  These CTs are now available for GBP 2-3 for small qtys and would have very high accuracy over a wide range of currents.

3. In your earlier posts, you mentioned about a unit costing around £ 70 to control the heater ckt.  What is this unit and what does it do.

 

 

Robert Wall's picture

Re: PHASECAL and Serial Statements

Robin is away at present and will no doubt respond fully on his return.

It is not quite so simple as your first point suggests. The voltage signal is required to time the initiation of the zero crossing trigger, and this is notably absent in some of the dedicated i.c's.

In answer to your 2nd point, a ring core c.t. is not generally viable in the UK as the connections between the incomer and the consumer's main switch are sealed by the supply authority, therefore fitting a ring core c.t. would be unattractive to most constructors.

calypso_rae's picture

Re: PHASECAL and Serial Statements

Thanks, Robert, for your reply. 

I don't think there's anything I can add to points 1 and 2 expect to say that, for the purpose of calculating real power, the effect of phase shift between the V and I waveforms makes very little effect.  I have long since given up worrying about this.  All my recent builds have had phaseCal = 1 and appear to work fine with no appreciable error. 

The biggest source of error that I'm aware of is the tendency of the system to drift by up to a Watt in one direction of the other (or neither) when zero current is present at the CT.  This effect can occur when the CT's mid-point lies close to one of the ADC's decision points, which can cause tiny amounts of noise to be amplified.  In a real system, however, I do not believe that this effect would cause any problem.  For one thing, most digital meters require at least 10 Watts to flow before user consumption is registered.  For another, the net current at the supply point for a domestic premises is unlikely to be exactly zero (or constant) for any appreciable amount of time.

As for point 3, that would have been a Carlo Gavazzi power controller (RJ1P23V30E) that I used before devising the triac-based approach.  Although that unit could be instructed to vary the power to my immersion in various ways (phase-angle and several burst-mode options), its performance was less than ideal because of various limiting factors.  My Mk2 logic, in which the measurement and control logic operate continuously and are fully integrated, is a much better arrangement, IMHO.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.