Archived Forum

The default value of 1.7 is only valid (and then only a starting value) when using the methods in emonLib. It would be possible to make that an interpolation (1.7 is extrapolation) by reversing the order in which voltage and current are read, but that would raise problems with backwards compatibility.

If you don't use all of emonLib, then you need to calculate or adjust the phase shift and/or the order of reading the samples in order to obtain the least bad alignment under typical conditions. (I put it that way because both transducers' phase shifts are variable, and you're using a time shift to compensate for a phase shift, which isn't right but it's the best we can do - easily.)

[N.B. You need to click "List" when you've uploaded the attachment, before you post.]

Heres the speadsheet again - sorry

EmonLib uses the first example on the spreadsheet - have a look please.

Phase shifts between the measured values for AC voltage and current have very little effect when calculating real power.  I posted a video about this some months ago.  Even with a PHASECAL value of 5 (that's an extrapolation of several samples for each voltage value), the effect was minimal.  But if you're wanting to calculate some other parameter, the effect of phase mismatch could be much greater.

ianjm: You didn't need to attach it again, I had already done that for you! ! !

Robin

Been away and just watched your video - I had watched it some time ago but really didn't understand what you were talking about then.  However I was impressed enough to want to get my own PV divert working and started putting my system together and learning more about the software.  I fired it up on Friday and its working a treat - thanks for your input.
I agree for a PV divert what you showed would be correct - the voltage is only needed to work out the direction of power flow and even if that maths is not quite correct the bucket method will still work.

I noticed in your video that you had calculated your ratio to 0.8.
The spreadsheet I posted gives a value of 0.86 for a single CT setup - it seems to match well with what you derived.
 

I have a attached a revised version - I found a small error when trying to flag up a setup that would never work (all the values go red when there is not enough time in a cycle to read the CTs and voltage)

Ian

Ian, glad to hear that you have a working system to experiment with.  Just picking up on a couple of your points:

"the voltage is only needed to work out the direction of power flow".  I'm not sure what you're saying here.  When diverting surplus power, the voltage waveform - along with the current - is used to calculate real power.  Calculating V*I is always going to give a better result than using I*I.  For this purpose, the phase-alignment between these waveforms, as can be adjusted using phaseCal, is non-critical.

I noticed in your video that you had calculated your ratio to 0.8.  What I intended to convey was that I had found the optimal value for my rig by measurement to be around 0.8.  With all the unknowns of the physical hardware, I would not have much confidence in any calculated value.  At least two tools have been posted which allow the optimal value of phasecal to be determined by measurement.
 

With all the unknowns of the physical hardware, I would not have much confidence in any calculated value.

I second that. The values I published were measurements made on one (in the case of the v.t.) or 3 (in the case of the c.t.) units. They are not figures guaranteed or even provided by the manufacturer, and might not even be "typical". So any phase correction you calculate on the basis of those is a 'best guess' if you cannot do any better, and a starting value if you can.

ianjm said: It has bugged me for a while that when correcting leading phases then the values should be moving backwards however the standard sketch has a value of 1.7 for correction which moves phasing even more forward!

It is a bit hard to get your head round but this is correct.

Take the case where both transformers have no phase shift.

For the standard library the current sample is taken about 106µs after the voltage sample and the voltage samples are about 377µs apart so what we need to know is what the voltage will be 106µs after the last voltage sample. Since this is in the future we need to extrapolate from the last voltage sample using it and the previous sample.

Now 106/377 = 0.28 so PHASECAL would need to be 1.28

If the current transformer has more lead than the voltage transformer then the current sample is even further in the future than the last voltage sample. If this lead is 158µs then we need to know the voltage 106+158=264µs after the last sample.

Now 264/377 = 0.7 so PHASECAL should be 1.7

In my own code I hold the current sample until the next voltage sample and then do the calculation. This way I can use interpolation which has less error than extrapolation.

Phase correction does make a significant difference when the power factor is much less than 1, for example in the PV power at night.

Thanks for the comments

Robin, Robert - I agree with you that a measured value is always going to be better than one from a table.  However you should put a big caveat on the figure as its only valid for the voltage, frequency and load it was measured against.

Use the attached spreadsheet and vary the delays for voltage and load.
The PHASECAL for one CT on "CT then V" is is 0.86 and varies between 0.78 and 1.08.  So at best the PHASECAL value should be a midpoint of your system or where it spends most of the day.

Martin 
I have attached an updated spreadsheet that has an extra tab on for V then CT.
You are correct that the PHASECAL value will be greater than 1 as its trying to predict the future.
Your numbers are not quite correct - you need to add to the cycle time another ADC read and decrement the phase shift for a CT read.

This gives 533/377 = 1.47
at 240v and low load levels

The only way I can see it getting to 1.7 would be at high mains voltage on a heavy load  - this would not be a typical operating condition.

IMHO the attached spreadsheet is a good starting point for PHASECAL providing they are using CTs and voltage transformers from the openenergy web site.  It is better to work out a value off your own equipment provided you can, find a resistive load that gives your normal/average load, do it when the voltage and frequency are average for your system and you know how to adapt your script to do the calculations.

Someone needs to change the values of PHASECAL on the standard emonTX.  1.7 is wrong.
The end of this page on the building blocks needs changing it suggests using a value of 1.28 its wrong and misleading
http://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor...

Ian

The end of this page on the building blocks needs changing it suggests using a value of 1.28 its wrong and misleading

Really? The values I measure are very close to those that Martin has measured - quite independently as far as I'm aware. I had the cycle time as 370 µs and the interval between readings as 112.5 µs, giving me 1.30, and Martin got 377µs and 106 µs, to give 1.28. I don't think 1.28 is far wrong.

you should put a big caveat on the figure as its only valid for the voltage, frequency and load it was measured against.

Pardon me, but don't the graphs in the reports actually show the variation with the measured quantity?

Robert
I'm not disputing your values of 370 & 112.5 but they don't give a PHASECAL of 1.28 its wrong

The elapsed time between the first voltage and the last CT value is 370 + 112.5 = 482.5
however you need to adjust for the phase shift made by the CT and voltage transformer

using Voltage transformer 250µs and CT 180µs  - you need to add 70 microseconds on to account for phase shifts

This gives a total time of 552.5µs
552.5/370 = 1.49 

You have to include the phase shifts at the start and the end to get the correct values when reading V then CT.

For CT then V you start and end with a V so they cancel out and the overall cycle time is the same - the CT reading however needs adjusting for its phase adjustment of -180µs

Have a look at the spreadsheet.
 

"Pardon me, but don't the graphs in the reports actually show the variation with the measured quantity?"

Yes they do the graphs do show the changes in phase movement against voltage and load. I have not seen any software yet that tries to implement varying the PHASECAL value dependent on measured voltage and power and above you ignored them completely.

Robin, Robert - I agree with you that a measured value is always going to be better than one from a table.  However you should put a big caveat on the figure as its only valid for the voltage, frequency and load it was measured against.

I have never advocated using any particular value for phaseCal.  I have only provided tools by which its optimal value can be measured.  As Martin has pointed, by delaying one set of measurements with respect to the other, the optimal value can always be moved into the interpolation zone so that extrapolation is no longer required.

In virtually all of my Mk2 PV Router sketches, current is sampled before voltage.  By means of this simple change, the optimal value of phaseCal is moved sufficiently close to "1" so that further refinement becomes unnecessary in practical terms.

Robert
I'm not disputing your values of 370 & 112.5 but they don't give a PHASECAL of 1.28 its wrong

Yes they do - nearly (1.304) and it's very close.

You need to bear in mind that recently a small change was made to emonLib that speeded up the loop a little, which had the effect of changing the value of PHASECAL required because it shortened the time between reading the voltages but did not affect the time between reading current and voltage. The page "Explanation of the phase correction algorithm" where 1.28 appears was written before that change.

I reversed the change and I have just finished experimenting with an emonTx and with the voltage and current inputs linked, which is exactly what the "Explanation of the phase correction algorithm" page means with "will correct the inherent software error of 2° ", I found I needed a value of PHASECAL of 1.27 to give me a power factor of 0.99999. Here:

Time = 200 ms for 528 samples. CT1 Real Power = 18753.87 W, App Power = 18754.07 VA, Irms = 96.726 A,  pf =0.999989 V = 193.89
Time = 201 ms for 528 samples. CT1 Real Power = 17947.41 W, App Power = 17947.58 VA, Irms = 94.616 A,  pf =0.999991 V = 189.69

That's close enough for me. As you can see, the loop time has increased to nearly 380 µs.

If anyone wishes to confirm my measurements, with a standard emonTx, link AIO2 and AIO3, and bridge the 100 kΩ forming the top half of the ac input voltage divider with 4.7 kΩ. This forces both inputs to see exactly the same voltage and thus shows the phase error solely due to the timing difference, which is what we're proving.

[Edit: The spreadsheet does not have sufficient range to cater for the Ideal v.t., the one presently stocked.]

I finally had time to look your spreadsheet Ian and I think you've got a sign wrong somewhere. If the voltage lead is greater than the current lead then the current is lagging the voltage. It also seems like a very complicated way to do a very simple calculation.

This is what I think your inputs are:

voltage phase lead due to transformer 250µs

current phase lead due to transformer 180µs

current phase lead due to ADC delay 106µs

time between voltage samples 377µs

Now the calculation:

current phase lead at input pins = 180-250 = -70µs (i.e. in this case current lags voltage at the pins)

current phase lead after ADC = -70 + 106 = 36µs

PHASECAL = 1 + 36/377 = 1.095

I decided to use Robin's PHASCAL calculator script that I have slightly modified it so that it also outputs the average cycle time and the ADC average read time (average over 250 mains cycles).  I have ran this for V then CT against my immersion heater 3kW.  The sketch and results are attached.

These are the results

PhasecalChecker_VCT_1CT_CT3
Voltage then CT One CT
The initial value of PHASECAL is 0.70
PHASECAL:0.70 Cycle:407.50 ADCdelay:112.68 RealP:10996.20, appP:11199.95 PF:0.98181
PHASECAL:0.80 Cycle:407.17 ADCdelay:112.73 RealP:11003.07, appP:11189.29 PF:0.98336
PHASECAL:0.90 Cycle:407.19 ADCdelay:112.73 RealP:11009.97, appP:11183.56 PF:0.98448
PHASECAL:1.00 Cycle:407.32 ADCdelay:112.66 RealP:11010.32, appP:11173.95 PF:0.98536
PHASECAL:1.10 Cycle:407.61 ADCdelay:112.67 RealP:11042.37, appP:11194.80 PF:0.98638
PHASECAL:1.20 Cycle:407.52 ADCdelay:112.66 RealP:11062.11, appP:11210.16 PF:0.98679
PHASECAL:1.30 Cycle:407.60 ADCdelay:112.68 RealP:11076.48, appP:11219.88 PF:0.98722
PHASECAL:1.40 Cycle:407.47 ADCdelay:112.71 RealP:11101.37, appP:11244.08 PF:0.98731
PHASECAL:1.50 Cycle:407.37 ADCdelay:112.75 RealP:11117.55, appP:11256.65 PF:0.98764
PHASECAL:1.60 Cycle:407.21 ADCdelay:112.77 RealP:11155.34, appP:11297.68 PF:0.98740
PHASECAL:1.70 Cycle:407.15 ADCdelay:112.78 RealP:11181.44, appP:11327.69 PF:0.98709

This would seem to give a PHASECAL of arround 1.5

I am now even more confused 

I started my spreadsheet to try and get to grips with what the PHASECAL should be set to for a 3CT setup - I have them all set to 1.25 which is not the right value.

I have re-looked at my spreadsheet and its possible to get a value of 1.45 for V then CT calculations -  if you take the V to V as the cycle time  and add 70µs onto the time to the next CT read. (407 + 112.7 + 70)/407

However when the CT and voltage transformers were tested they all showed leading values so I would expect that we should be subtracting to realign!  However aligning everything to the voltage transformer the CT is leading by about 70µs when using 250 & 180.

Now I have a working setup in my garage I will do some more testing tomorrow.

Any thoughts on the above?

Ian

Ian, could your problem be that you are using the wrong frame of reference?  As far as the processor is concerned, it has absolutely no knowledge of the v.t. phase shift nor of the actual phase of the supply. All it knows about timing is the voltage it sees. Therefore, it makes sense to me to forget about c.t. and v.t. phase lead, and consider only the difference between them. (But we do need to worry about its sign.)

On that basis, the c.t. leads less than the v.t. so it exhibits a lag (as Martin said), of say 2½° (that's 139 µs) with respect to the v.t., which is the processor's private reference.

Let's assume you're using the standard emonLib methods. The current reading takes place later than (lags) the present voltage reading by (say) 112 µs. Both are going in the same direction so add those and you get 251 µs.

Now to get an estimate of the voltage 251 µs later (i.e. in the opposite direction to the previous voltage), you must extrapolate. The base time is the time between voltage readings, say 360 µs.  The way the equation is arranged, a coefficient of 0 returns the last value (earlier), 1 returns the present value, and we want the value 251/360 ths further on (later).  251/360 = 0.697 so our calibration factor is 1.697.

That's where the 1.7 comes from.

If you reverse the order of reading the samples, the only thing that changes is the current reading is now earlier than the present voltage reading by 112 µs, so you go back 112 µs and forward 139 µs, so forward a nett 27 µs. It's easy to see now that the coefficient is very close to unity, 1.075 to be exact.

The current reading takes place later than (lags) the present voltage reading by (say) 112 µs.

Sorry Robert but this is incorrect. The current sample is later in the cycle than the voltage sample and therefore leads the voltage sample as I said above.

Martin, what are you on about? Something that happens earlier in time leads, something that happens later in time lags. We have anchored to the time at which the present voltage sample arrives and if the current sample arrives later, it lags.

The voltage sample is older than the current sample so it lags behind the current sample, therefore the current sample leads.

Imagine f if you sampled the voltage twice instead of sampling the current and then plotted both samples at the same point on the x axis. The second set of samples (the ones that would have been current) will always be a further into the cycle than the first set and will clearly be seen to be leading.

We have anchored to the time at which the present voltage sample arrives and if the current sample arrives later, it lags.

This is the crux of the confusion. The calculation is done after the current sample arrives. At this point the voltage sample is old and therefore lags.

In the original emonLib calcVI() routine, the voltage sample was taken first.  For this situation, a phasecal value of 1.7 was appropriate for standard hardware. 

In most of my Mk2 sketches, I've sampled the current value before the voltage one.  This has the effect of reducing the optimal phasecal value to much closer to 1.

I'm not aware of any recent changes that have been made to emonLib as I don't use it.

I have a spare Mk2 rig on the bench.  Tomorrow, I will run my phasecal checker sketch on it and post the results.

Yes, I think we are all agreed that PHASECAL should be around 1.7 for voltage first operation and the value of 1.5 that Ian measured above is probably about right. So, working back from this...

407 x 0.5 = 203.5 ie. total current lead is 203.5µs
now, lead due to ADC delay is 112.7µs so current lead due to transformers is:
203.5 - 112.7 = 90.8µs
assuming we believe the CT lead value of 180µs then the voltage lead must be:
180 - 90.8 = 89.2µs or 1.6 degrees

The only conclusion you can draw from this is that the voltage phase lead value of about 250µs from the Mascot report is wrong. This is an issue that I've raised before but I don't think I managed to convince anyone.

This is the diagram from the Mascot report...

To my eye there is negligible phase shift here as the peaks are aligned. What is clearly visible is harmonic distortion around the zero crossings due to the transformer approaching saturation. If we corrected by the full 5.7 degrees we would probably make the error larger because the peaks, where most of the power is, would now be misaligned.

The CT on the other hand is nowhere near saturation so we can probably believe those values.

The voltage wave is not a pure sinusoid, so you cannot say it has one phase shift. Each harmonic component has its own. The objective, that we mustn't lose sight of, is to arrive at a correction that gives unity power factor for a purely resistive load. If the fundamental has a small error that is balanced by the power in the higher order harmonics, then so be it. I would still maintain that most of the power is in the fundamental, and it is the phase shift of that which is the most important. Here is the harmonic analysis of my local mains:

As you can see, the 3rd and 5th harmonics are around 1½% of the fundamental, so the power in all the harmonics is a small fraction of the total, and that seems to support the view that the phase shift of the fundamental is important.

This is what the X-Y plot of the Mascot looks like at 240 V. Ideally, the figure should be a perfect ellipse, but the distortion has squeezed the tips. If it were a perfect ellipse, the phase shift would be sin^-1(height at zero / peak-peak height), alternatively sin^-1(width at zero / peak-peak width).

And as I've noted in the past and Ian has reiterated recently, a fixed value is a compromise and it would take a two-way lookup table to return a value that offered a better correction over a wider range of currents and voltages.

Martin, all I can say about your definition of lead and lag is it's opposite to everyone else's.

Martin, all I can say about your definition of lead and lag is it's opposite to everyone else's.

I can't believe you said that Robert, you're the last person I thought I'd get into a silly argument with and to dismiss my reasoned logic in such an offhand manner without any explanation is not like you.

I think you've said yourself that swapping the ADC order around to read current first is better because it partially compensates for the current lead from the transformers. Why do you think that is? It's because once swapped the current does indeed lag the voltage and therefore cancels some of the lead due to the transformers.

All of my sketches treat the ADC delay between the voltage and current samples as current lead...

#define I1PHASESHIFT (((I1LEAD+63)*256)/400) // phase shift in voltage to align to current samples

... and they compensate for this lead perfectly with perfect inputs.

This is a plot of voltage (blue) and current (red) samples with the 2 inputs connected together that I tried to get you to visualise in my previous post..

Is that not your definition of lead too?

I think it just depends on which direction you measure time in.  Usually, whichever one happens first is considered to be the one leading.  Above, your red plot hits the x-axis first, so it is leading the blue.   The "oldest" is the leader, because it got there first.

The standard definition for inductors for example is that voltage leads current, which means voltage hits zero before current.

Here some phaseCal results for a rig that was handy.  The sketch is my PhasecalChecker as posted on my Summary Page

The hardware is pretty much standard.  Instead of an external AC supply, I'm using one of the outputs from a dual 9V mains transformer; the second output provides power for the processor via a 5V regulator.  The board is a sub-equipped emonTx rather than an Arduino.

Within the phaseCal range 1.0 to 2.0, my power Factor is 1.00, and it can be seen to move away from this value symmetrically on either side.   This suggests that the optimal value is around 1.5.  The transformer that I'm using for my voltage sensor is cheap and cheerful, very probably with more distortion than a better quality one.  This probably explains why the optimal phaseCal value, when measuring current before voltage, is higher than I would have expected.  In practice, by using the value Phasecal = 1 (or omitting this calculation altogether), the resulting error will be insignificant for the purpose of calculating real power.

Results taken with PhasecalChecker.ino 12/8/13

value of PHASECAL_MAX?
 PHASECAL_MAX = 3.00
value of PHASECAL_MIN?
 PHASECAL_MIN = 0.00
value of PHASECAL_INCREMENT?
 PHASECAL_INCREMENT = 0.20
In NORMAL mode ...

The initial value of PHASECAL is 0.00
real power = 58186.26, apparent power = 60163.77, power factor = 0.97
real power = 51381.30, apparent power = 52419.88, power factor = 0.98
real power = 51815.91, apparent power = 52859.42, power factor = 0.98
real power = 52268.26, apparent power = 53311.65, power factor = 0.98
real power = 52138.03, apparent power = 53181.19, power factor = 0.98
PHASECAL is now 0.20
real power = 51733.14, apparent power = 52548.88, power factor = 0.98
real power = 51532.74, apparent power = 52346.46, power factor = 0.98
real power = 51808.50, apparent power = 52620.50, power factor = 0.98
real power = 52197.41, apparent power = 53012.26, power factor = 0.98
real power = 52170.16, apparent power = 52984.75, power factor = 0.98
PHASECAL is now 0.40
real power = 51791.69, apparent power = 52400.92, power factor = 0.99
real power = 51721.46, apparent power = 52327.74, power factor = 0.99
real power = 52027.92, apparent power = 52633.91, power factor = 0.99
real power = 52429.34, apparent power = 53032.66, power factor = 0.99
real power = 52332.83, apparent power = 52937.71, power factor = 0.99
PHASECAL is now 0.60
real power = 51971.85, apparent power = 52411.98, power factor = 0.99
real power = 51892.76, apparent power = 52326.61, power factor = 0.99
real power = 52313.26, apparent power = 52746.59, power factor = 0.99
real power = 52640.06, apparent power = 53072.32, power factor = 0.99
real power = 52235.80, apparent power = 52669.92, power factor = 0.99
PHASECAL is now 0.80
real power = 52144.39, apparent power = 52449.00, power factor = 0.99
real power = 52027.59, apparent power = 52324.97, power factor = 0.99
real power = 52384.72, apparent power = 52681.62, power factor = 0.99
real power = 52764.58, apparent power = 53060.60, power factor = 0.99
real power = 52893.93, apparent power = 53189.89, power factor = 0.99
PHASECAL is now 1.00
real power = 52433.09, apparent power = 52636.83, power factor = 1.00
real power = 52344.41, apparent power = 52540.15, power factor = 1.00
real power = 52303.91, apparent power = 52500.20, power factor = 1.00
real power = 53072.14, apparent power = 53267.28, power factor = 1.00
real power = 52937.12, apparent power = 53131.37, power factor = 1.00
PHASECAL is now 1.20
real power = 52846.79, apparent power = 52982.27, power factor = 1.00
real power = 52412.46, apparent power = 52543.02, power factor = 1.00
real power = 52489.12, apparent power = 52619.33, power factor = 1.00
real power = 52368.28, apparent power = 52498.40, power factor = 1.00
real power = 52878.98, apparent power = 53008.03, power factor = 1.00
PHASECAL is now 1.40
real power = 53332.03, apparent power = 53436.00, power factor = 1.00
real power = 53362.95, apparent power = 53463.17, power factor = 1.00
real power = 52915.31, apparent power = 53014.39, power factor = 1.00
real power = 52622.85, apparent power = 52721.80, power factor = 1.00
real power = 52554.28, apparent power = 52652.85, power factor = 1.00
PHASECAL is now 1.60
real power = 52845.94, apparent power = 52950.63, power factor = 1.00
real power = 52931.96, apparent power = 53034.88, power factor = 1.00
real power = 53389.03, apparent power = 53494.23, power factor = 1.00
real power = 53314.85, apparent power = 53419.40, power factor = 1.00
real power = 53131.62, apparent power = 53234.27, power factor = 1.00
PHASECAL is now 1.80
real power = 52837.65, apparent power = 52974.07, power factor = 1.00
real power = 52857.82, apparent power = 52995.90, power factor = 1.00
real power = 52941.02, apparent power = 53079.35, power factor = 1.00
real power = 53535.10, apparent power = 53679.38, power factor = 1.00
real power = 53526.32, apparent power = 53670.28, power factor = 1.00
PHASECAL is now 2.00
real power = 53245.93, apparent power = 53450.50, power factor = 1.00
real power = 53005.17, apparent power = 53215.47, power factor = 1.00
real power = 52636.24, apparent power = 52842.29, power factor = 1.00
real power = 53073.73, apparent power = 53285.41, power factor = 1.00
real power = 53021.87, apparent power = 53232.29, power factor = 1.00
PHASECAL is now 2.20
real power = 52699.62, apparent power = 52992.79, power factor = 0.99
real power = 52572.82, apparent power = 52878.34, power factor = 0.99
real power = 52543.35, apparent power = 52856.41, power factor = 0.99
real power = 53225.39, apparent power = 53541.09, power factor = 0.99
real power = 53257.29, apparent power = 53578.65, power factor = 0.99
PHASECAL is now 2.40
real power = 53175.37, apparent power = 53600.26, power factor = 0.99
real power = 52725.69, apparent power = 53171.01, power factor = 0.99
real power = 52634.97, apparent power = 53080.27, power factor = 0.99
real power = 53101.29, apparent power = 53547.31, power factor = 0.99
real power = 53296.34, apparent power = 53748.43, power factor = 0.99
PHASECAL is now 2.60
real power = 53596.05, apparent power = 54190.81, power factor = 0.99
real power = 52798.87, apparent power = 53399.68, power factor = 0.99
real power = 52910.12, apparent power = 53518.97, power factor = 0.99
real power = 52835.39, apparent power = 53445.73, power factor = 0.99
real power = 53157.37, apparent power = 53777.53, power factor = 0.99
PHASECAL is now 2.80
real power = 53860.62, apparent power = 54648.81, power factor = 0.99
real power = 53813.90, apparent power = 54644.28, power factor = 0.98
real power = 53396.58, apparent power = 54201.86, power factor = 0.99
real power = 53093.16, apparent power = 53900.82, power factor = 0.99
real power = 53020.11, apparent power = 53818.02, power factor = 0.99
PHASECAL is now 3.00
real power = 53387.10, apparent power = 54372.14, power factor = 0.98
real power = 53364.24, apparent power = 54411.18, power factor = 0.98
real power = 54031.69, apparent power = 55093.42, power factor = 0.98
real power = 53906.23, apparent power = 54960.88, power factor = 0.98
real power = 54023.96, apparent power = 55075.04, power factor = 0.98
End of run, please restart to repeat

dBC said: Above, your red plot hits the x-axis first, so it is leading the blue.

At least someone agrees with me :) Hopefully you can also see that if you take a sample and then take another sample a short time later but you consider both samples to have occurred at the same time (i.e. they belong to the same sample pair in emonLib) then the second set of samples will lead the first set because they will get to the x-axis first.

Robin - why don't you display more decimal places for power factor then you'll see the optimum PHASECAL value more clearly?

Yes, Martin, I could.  I recall someone doing exactly that when I first posted that sketch last year. 

Because the V and I waveforms are nominally in phase, the effect on Power Factor of any relative shift that is introduced between them is minimal, and is the same in both directions.  Although insensitive, this method has the advantage of not being affected by any distortion of the underlying mains profile. 

There are no doubt more sensitive ways to detect small differences in phase-shift between signals that are nominally aligned.  But for the purpose of calculating real power (which has always been my primary interest), the simple method that I've used to date has proved to be perfectly adequate.

then the second set of samples will lead the first set because they will get to the x-axis first.

I'm having trouble getting my head around that part.  If you did take 2 readings 100 usecs apart say, but you really wanted to take them at the same time, and they both came back as 0, that means the first one was leading the second by 100 usecs right?

Yes, that's correct. For the real signals, as seen at the input pins, the first signal must have been leading the second by 100µs, or in other words the second signal was lagging by 100µs. The delay that you have introduced by delaying the second read has compensated for this lag so this delay is equivalent to a lead in the second signal - which is exactly my point and the issue that Robert seems to be having trouble with.

I think I get what you're saying.  Because you were forced to measure the first signal 100 usecs earlier than you wanted to, it's as if you shifted it to the right by 100 usecs, or added 100 usecs of lag to it.

I guess it is a point of reference issue.  If you're sitting in the train, it looks like the world is hurtling towards you at 100km/hr.

Spot on!

You are right that you can look at these things from several points of reference but you have to be consistent. The original statements that I took issue with are....

On that basis, the c.t. leads less than the v.t. so it exhibits a lag (as Martin said), of say 2½° (that's 139 µs) with respect to the v.t., which is the processor's private reference.

Let's assume you're using the standard emonLib methods. The current reading takes place later than (lags) the present voltage reading by (say) 112 µs. Both are going in the same direction so add those and you get 251 µs.

This is wrong. The later current reading is equivalent to adding lead to the current so the two values are not "going in the same direction". You need to subtract them, not add them, so the result is 139 - 112 = 27µs of lag and PHASECAL will be less than 1.

I don't believe this is a real world value as we always see a PHASECAL value greater than 1 and the reason it's wrong is because the Mascot transformer doesn't exhibit that much phase lead as I said above.

Ive just done a run of CT then V - ive moved the ADC calc away from the main test code.

PhasecalChecker_CTV_1CT_CT3
CT then Voltage - One CT
The initial value of PHASECAL is 0.40
ADCdelay:112.11
PHASECAL:0.40 Cycle:398.74 RealP:10988.43, appP:11145.65 PF:0.98589
PHASECAL:0.45 Cycle:398.59 RealP:11000.45, appP:11163.04 PF:0.98543
PHASECAL:0.50 Cycle:398.87 RealP:11016.61, appP:11175.25 PF:0.98580
PHASECAL:0.55 Cycle:399.04 RealP:11058.15, appP:11212.39 PF:0.98624
PHASECAL:0.60 Cycle:398.98 RealP:11067.41, appP:11216.43 PF:0.98671
PHASECAL:0.65 Cycle:399.02 RealP:11101.54, appP:11244.71 PF:0.98727
PHASECAL:0.70 Cycle:398.82 RealP:11046.24, appP:11188.36 PF:0.98730
PHASECAL:0.75 Cycle:398.80 RealP:11061.10, appP:11199.37 PF:0.98765
PHASECAL:0.80 Cycle:398.62 RealP:11067.33, appP:11204.46 PF:0.98776
PHASECAL:0.85 Cycle:398.50 RealP:11078.09, appP:11216.11 PF:0.98769
PHASECAL:0.90 Cycle:398.52 RealP:10962.14, appP:11096.49 PF:0.98789----------------
PHASECAL:0.95 Cycle:398.52 RealP:10964.26, appP:11101.07 PF:0.98768     PHASCAL 
PHASECAL:1.00 Cycle:399.01 RealP:10958.67, appP:11092.66 PF:0.98792     around here
PHASECAL:1.05 Cycle:399.08 RealP:10993.46, appP:11128.21 PF:0.98789----------------
PHASECAL:1.10 Cycle:398.99 RealP:10988.95, appP:11125.09 PF:0.98776
PHASECAL:1.15 Cycle:399.04 RealP:11018.05, appP:11156.14 PF:0.98762
PHASECAL:1.20 Cycle:398.98 RealP:11011.14, appP:11151.07 PF:0.98745
PHASECAL:1.25 Cycle:399.03 RealP:11025.61, appP:11167.99 PF:0.98725
PHASECAL:1.30 Cycle:398.91 RealP:11018.12, appP:11161.50 PF:0.98715
PHASECAL:1.35 Cycle:398.76 RealP:11029.46, appP:11176.00 PF:0.98689
PHASECAL:1.40 Cycle:398.74 RealP:11007.35, appP:11158.83 PF:0.98643
PHASECAL:1.45 Cycle:398.74 RealP:11022.79, appP:11179.85 PF:0.98595
PHASECAL:1.50 Cycle:398.70 RealP:11017.10, appP:11178.44 PF:0.98557
PHASECAL:1.55 Cycle:398.68 RealP:11018.12, appP:11182.73 PF:0.98528
PHASECAL:1.60 Cycle:398.58 RealP:11015.94, appP:11188.46 PF:0.98458
PHASECAL:1.65 Cycle:398.48 RealP:11043.43, appP:11221.74 PF:0.98411
PHASECAL:1.70 Cycle:398.42 RealP:11024.84, appP:11209.65 PF:0.98351

I have a revised spreadsheet that only shifts the CT values - the voltage here is a bit high which should mean the gap will be bigger than 70µs say 80µs  this calculates a value of 0.92 which just fits in with the above.  With 70µs its 0.98 still close.

I'll try running a 3CT test and see what that produces.

The current reading takes place later than (lags) the present voltage reading by (say) 112 µs.

Sorry Robert but this is incorrect. The current sample is later in the cycle than the voltage sample and therefore leads the voltage sample as I said above.

I've finally realised where the confusion has come in. I was using "reading" to mean the act of measuring a sample. You meant that if the current is sampled later than the voltage, the effect is the same as if the current sample was taken synchronously with the voltage and the current wave was leading the voltage wave.

This all needs writing up but with very careful choice of words, and good diagrams.

If it was just down to wording I would have let this go but the fact that the effect of the ADC delay is equivalent to a current lead, not a lag as you previously said, means that your calculations are wrong and this is what is important.

As I said in my last post, your conclusion from these statements is wrong...

On that basis, the c.t. leads less than the v.t. so it exhibits a lag (as Martin said), of say 2½° (that's 139 µs) with respect to the v.t., which is the processor's private reference.

Let's assume you're using the standard emonLib methods. The current reading takes place later than (lags) the present voltage reading by (say) 112 µs. Both are going in the same direction so add those and you get 251 µs.

As we now agree, the later current reading is equivalent to adding lead to the current so the two values are not "going in the same direction". You need to subtract them, not add them, so the result is 139 - 112 = 27µs of lag.

Here are the results from my 3 CT test - 3kW immersion heater voltage was around 240V RMS

PHASECAL_MAX = 1.00
value of PHASECAL_MIN?
PHASECAL_MIN = 0.60
value of PHASECAL_INCREMENT?
PHASECAL_INCREMENT = 0.02
PhasecalChecker_CTV_3CT_CT1
CT then Voltage - One CT
The initial value of PHASECAL is 0.60
ADCdelay:56.17
PHASECAL:0.60 Cycle:401.30 RealP:11157.61, appP:11300.87 PF:0.98732
PHASECAL:0.62 Cycle:401.22 RealP:11157.70, appP:11308.89 PF:0.98663
PHASECAL:0.64 Cycle:401.25 RealP:11155.45, appP:11306.70 PF:0.98662
PHASECAL:0.66 Cycle:401.16 RealP:11181.59, appP:11332.05 PF:0.98672
PHASECAL:0.68 Cycle:401.19 RealP:11161.97, appP:11309.20 PF:0.98698
PHASECAL:0.70 Cycle:401.08 RealP:11142.35, appP:11289.53 PF:0.98696
PHASECAL:0.72 Cycle:401.00 RealP:11128.88, appP:11274.21 PF:0.98711
PHASECAL:0.74 Cycle:400.83 RealP:11107.14, appP:11251.77 PF:0.98715
PHASECAL:0.76 Cycle:400.90 RealP:11116.91, appP:11264.18 PF:0.98692
PHASECAL:0.78 Cycle:400.77 RealP:11115.33, appP:11263.48 PF:0.98685
PHASECAL:0.80 Cycle:400.78 RealP:11125.73, appP:11269.91 PF:0.98721----------------------
PHASECAL:0.82 Cycle:400.86 RealP:11140.33, appP:11286.11 PF:0.98708
PHASECAL:0.84 Cycle:400.76 RealP:11132.86, appP:11279.49 PF:0.98700
PHASECAL:0.86 Cycle:400.76 RealP:11148.56, appP:11294.02 PF:0.98712

PHASECAL:0.88 Cycle:400.76 RealP:11169.53, appP:11316.60 PF:0.98700
PHASECAL:0.90 Cycle:400.74 RealP:11161.64, appP:11309.80 PF:0.98690
PHASECAL:0.92 Cycle:400.68 RealP:11153.65, appP:11299.72 PF:0.98707
PHASECAL:0.94 Cycle:400.63 RealP:11158.05, appP:11302.92 PF:0.98718
PHASECAL:0.96 Cycle:400.62 RealP:11175.29, appP:11323.54 PF:0.98691
PHASECAL:0.98 Cycle:400.76 RealP:11176.22, appP:11324.82 PF:0.98688
PHASECAL:1.00 Cycle:400.68 RealP:11177.11, appP:11327.01 PF:0.98677

PHASECAL_MAX = 1.20
value of PHASECAL_MIN?
PHASECAL_MIN = 0.50
value of PHASECAL_INCREMENT?
PHASECAL_INCREMENT = 0.05
PhasecalChecker_CTV_3CT_CT2
CT then Voltage - One CT
The initial value of PHASECAL is 0.50
ADCdelay:56.26
PHASECAL:0.50 Cycle:401.07 RealP:11136.90, appP:11312.01 PF:0.98452
PHASECAL:0.55 Cycle:401.30 RealP:11140.60, appP:11321.28 PF:0.98404
PHASECAL:0.60 Cycle:401.23 RealP:11129.19, appP:11302.70 PF:0.98465
PHASECAL:0.65 Cycle:401.17 RealP:11120.47, appP:11288.77 PF:0.98509
PHASECAL:0.70 Cycle:401.09 RealP:11126.81, appP:11294.47 PF:0.98516
PHASECAL:0.75 Cycle:400.94 RealP:11140.86, appP:11305.10 PF:0.98547
PHASECAL:0.80 Cycle:400.82 RealP:11143.37, appP:11308.71 PF:0.98538
PHASECAL:0.85 Cycle:400.74 RealP:11150.21, appP:11313.28 PF:0.98559
PHASECAL:0.90 Cycle:400.66 RealP:11164.79, appP:11329.04 PF:0.98550
PHASECAL:0.95 Cycle:400.60 RealP:11163.17, appP:11325.18 PF:0.98569
PHASECAL:1.00 Cycle:401.21 RealP:11170.42, appP:11333.16 PF:0.98564
PHASECAL:1.05 Cycle:401.33 RealP:11154.44, appP:11315.68 PF:0.98575--------------
PHASECAL:1.10 Cycle:401.28 RealP:11171.02, appP:11336.66 PF:0.98539
PHASECAL:1.15 Cycle:401.24 RealP:11149.67, appP:11314.67 PF:0.98542
End of run, please restart to repeat

value of PHASECAL_MAX?

PHASECAL_MAX = 1.30
value of PHASECAL_MIN?
PHASECAL_MIN = 0.50
value of PHASECAL_INCREMENT?
PHASECAL_INCREMENT = 0.05
PhasecalChecker_CTV_3CT_CT3
CT then Voltage - One CT
The initial value of PHASECAL is 0.50
ADCdelay:56.26
PHASECAL:0.50 Cycle:401.03 RealP:11031.24, appP:11216.76 PF:0.98346
PHASECAL:0.55 Cycle:401.33 RealP:11054.00, appP:11242.56 PF:0.98323
PHASECAL:0.60 Cycle:401.21 RealP:11033.29, appP:11214.86 PF:0.98381
PHASECAL:0.65 Cycle:401.24 RealP:11073.42, appP:11252.32 PF:0.98410
PHASECAL:0.70 Cycle:401.06 RealP:11100.41, appP:11274.28 PF:0.98458
PHASECAL:0.75 Cycle:400.93 RealP:11129.61, appP:11301.28 PF:0.98481
PHASECAL:0.80 Cycle:400.82 RealP:11114.15, appP:11279.89 PF:0.98531
PHASECAL:0.85 Cycle:400.75 RealP:11145.92, appP:11310.75 PF:0.98543
PHASECAL:0.90 Cycle:400.65 RealP:11105.91, appP:11270.06 PF:0.98543
PHASECAL:0.95 Cycle:400.56 RealP:11135.43, appP:11296.59 PF:0.98573
PHASECAL:1.00 Cycle:401.21 RealP:11138.38, appP:11296.27 PF:0.98602
PHASECAL:1.05 Cycle:401.26 RealP:11142.39, appP:11300.93 PF:0.98597
PHASECAL:1.10 Cycle:401.25 RealP:11116.99, appP:11274.20 PF:0.98606
PHASECAL:1.15 Cycle:401.23 RealP:11148.43, appP:11303.42 PF:0.98629----------------
PHASECAL:1.20 Cycle:401.26 RealP:11139.54, appP:11296.11 PF:0.98614
PHASECAL:1.25 Cycle:401.31 RealP:11143.59, appP:11300.69 PF:0.98610
PHASECAL:1.30 Cycle:401.10 RealP:11112.81, appP:11271.10 PF:0.98596

This seems to be close to what my spreadsheet was predicting 
The selection of voltage and power from the graphs looks to be critical - get it wrong and the values are way out

When I started looking at this I tried to phase shift to the other side of the CT and Voltage transformer and this was wrong.
We need to look at this as the voltage signal being the driver and the CT lags by an offset
Deciding on an offset value will be difficult as it will drift as the RMS voltage changes and the current the CT is measuring changes.
Doing it empirically as above is better - I then need to decide what to set the values for the house CT and PV CT as they are not the same as the immersion heater I used to test with.

Ian,

I’m having trouble understanding what exactly it is you are trying to do in your spread sheets and, judging by the lack of replies, I suspect everyone else is too, if they are looking at them at all (if I’m wrong on this and someone is following them please shout up). I think you are over complicating the issue and this is probably because you have been misled by the phase shift values in the Mascot report.

I’ve probably spent more time looking into this and writing sketches than anyone else on this forum, Robin included, so please trust me here, this is the way it is...

The CT exhibits a phase lead that varies slightly with current.

The Mascot transformer also exhibits a phase lead that varies slightly with voltage. It also exhibits harmonic distortion which shifts the zero crossings in the direction of phase lead but, for the purpose of power measurement, this is not equivalent to phase lead. In practice the effective phase lead of the Mascot transformer is always less than the phase lead of the CT.

The only value that is important is the difference in phase shift between the 2 transformers. Because the CT exhibits more phase lead than the Mascot transformer this results in a phase lead for current at the Arduino pins. For this example let’s say this is 158µs.

Now if we take the current sample after the voltage sample then the delay in the current reading is equivalent to extra current phase lead and so needs to be added to the above shift. Let’s use 106µs for this.

Since the voltage is lagging behind the current we need a future voltage value and we have 2 previous samples V1 and V2, say 377µs apart.

The extrapolated voltage value will be: V2 + (V2-V1)x(106+158)/377 =  V2 + (V2-V1)x0.7 = V1 + (V2-V1)x1.7 this is what emonLib does.

If you use the voltage samples either side of the current sample instead then you can interpolate and the voltage will be V1 + (V2-V1)x0.7 this is what I do (obviously the value of 0.7 is just an example).

It really is that simple – honest!

-martin

Thanks Martin

Yes your right - I now know it is simple but a few here have been saying otherwise!

The values above were for a test sketch  - but it does indicate the method is right - I could apply that with my target sketch and get a good value for CT3 which has the immersion heater on.  The other two are house and PV which wont have the same load and cannot be simulated!

Now the hard bit - How do I work out the best values for my 3 CT setup?

The spreadsheet works - the cycle time and ADC time can be found accurately but picking the right values for the  VT and CT are not easy.  However the spreadsheet is not too far out.

If you know of a better and more accurate way of getting PHASECAL values please let me know.

Ian

I’ve probably spent more time looking into this and writing sketches than anyone else on this forum, Robin included, so please trust me here,

Some months ago, I was fairly pre-occupied by all this, and spent far too much time worrying about these details.  Having found that phase-errors between the V and I sample streams make very little difference when calculating real power, I've since moved on to other things.  I'm pleased to see that my PhasecalChecker still works. 

I'm wondering why there is so much interest in this topic now.  Is the precise phase-relationship between measured waveforms of practical use to anyone here?

If you know of a better and more accurate way of getting PHASECAL values please let me know.

I have never tried to measure current at more than one place, but many others have.  With a single phase installation, a standard emonTx can measure current at three places.  Using a suitable sketch, each set of current samples can be combined with a single set of voltage samples to provide three separate measurements (channels) of energy flow.

Each set of calculations would need its own phasecal value, but these values should not be difficult to ascertain.  The correct phasecal value for each channel is the one which provides a PF of 1 when drawing current through a resistive load.  So, for each CT in turn, just clip it around a standard load and run the sketch that you intend to use.

By running through a series of settings, as my PhasecalChecker sketch does, the effect of changing phasecal on each of the three measurement channels could be seen, and the optimal values obtained.

How does that sound? 

Ian,

You say your spreadsheet works but I'm not convinced. For a start you have the voltage lead greater than the current lead and I'm on the point of pulling my remaining hair out having said this so many times - THIS IS NOT RIGHT!

Also if I put the values from my last post into your spreadsheet (and I had to override your input validation to do this)..

ADC delay 106, cycle time 377, Voltage lead 22 (to get the correct difference), CT lead 180

I don't get the correct PHASECAL value of 1.7 for a single CT.

I did write a sketch for accurately calculating PHASECAL and posted it on here back in February but I've avoided mentioning it because I don't want to get into another long "debate" on it's validity and Robin's method seems to work well enough and is simple to understand.

Robin, with all your acquired knowledge on this subject it might help if you gave some support to the conclusions so that we can put this thread to bed. 

-martin

Robin, with all your acquired knowledge on this subject it might help if you gave some support to the conclusions so that we can put this thread to bed. 

My conclusion is that the optimal value of PHASECAL should be measured rather than worrying about how to calculate it.  The phase-relationship between the V & I sample streams is affected by all of the sensors' hardware and also the speed at which the program loops around, as well as the inherent delay of the ADC itself.  I've no doubt that your own phasecal checker is every bit as effective as the one that I posted last year.

Whether this thread is heading anywhere useful remains to be seen.  I don't think I have anything more to say on the subject.

Martin

Which version of the spreadsheet did you use?
On my post earlier I acknowledged that my original spreadsheet methodology was wrong and posted a new version. It wont give you 1.7 though - I ran a test for this earlier in the thread and got 1.5.  Ill run it again tomorrow using emonlib and see what it produces.

I cannot see how I can measure a value for my PV CT, my house CT or my grid CT - what do I use to simulate the load.  If I use my immersion heater it wont be the correct value for anything other than the immersion heater CT.

It would be nice to close this thread - could I have some good advice first please.

If I use my immersion heater it wont be the correct value for anything other than the immersion heater CT.

What is your concern there?  I think for a particular CT installed in its allocated "slot" in the sampling loop, you just need any old resistive load to enable you to tune the PF to 1.   So your immersion heater is probably as good as any.

Or are you concerned that a CT's phase shift varies with the current it's measuring?

Or are you concerned that a CT's phase shift varies with the current it's measuring?

I believe that is Ian's main concern. The only way out of that is to use a measurement/revenue grade c.t., for example the Magnelab SCT-075R series. The drawback is those are designed for 0.333 V rms output so you're immediately throwing away nearly two bits of ADC resolution by not using the full input range.

I don't know of another capable of the 1 V output we need to fully drive the emonTx input - they might exist but I've yet to find one.

Yes, I think that 333mV RMS might have become a bit of an unwritten industry standard for the revenue grade stuff.  The energy chip I use has an input range of +/- 500mV peak, which is pretty much a perfect match.  Its absolute maximum ratings are quite a bit higher, so you don't need to worry too much about overloads.

Which version of the spreadsheet did you use?

I used the last version you posted "V1.2 on V" and just changed the input values.

I'm not sure what advice to give you for actual values. For my system I just set it up using my floor heating as a large restive load for the house CTs and close to maximum PV for the solar CTs. It has tracked the supply and PV meters within 1% ever since.

As far as I am aware you are the only person who has attempted to calculate values from the test reports and that's why you've opened up this can of worms.

As far as I am aware you are the only person who has attempted to calculate values from the test reports...

My view is the value should be calculated as a starting point. The same goes for the voltage and current calibration constants. If the value you get with empirical testing is wildly different, then you should suspect a problem and investigate further. It might be that you were just unlucky with the tolerances, or it could be pointing to a genuine fault. Having got the starting point, then you should adjust the constants on test to give the closest match to whatever instrumentation you have or can beg or borrow.

If, Ian, you're concerned about the phase changing with load, then I think you have to aim to set it as close as you can under the conditions that prevail (not sure how to word this) for the largest quantity of energy use - or maybe that should be "at the current you're most interested in", and accept that errors will be present outside that range.

The only way out of that is to use a measurement/revenue grade c.t., for example the Magnelab SCT-075R series. The drawback is those are designed for 0.333 V rms output so you're immediately throwing away nearly two bits of ADC resolution by not using the full input range.

These also seem to be very well potted inside so you end up breaking it if you try to remove the internal resistor. They do some  CT's (not revenue grade) without the resistor, to order, so that could be another way.

(I'm guessing the  CT is probably the same except that they calibrate the revenue grade to a better tolerance with its resistor)?? 

Edit- Looking at  a UCT-0500-000 I have that looks to be only 1:360

My view is the value should be calculated as a starting point. The same goes for the voltage and current calibration constants. If the value you get with empirical testing is wildly different, then you should suspect a problem and investigate further.

That's what happened here really. The calculated value for PHASECAL from the reports is around 0.93 (using Robert's figures above), the empirical value from testing is around 1.5-1.7. These are wildly different, the investigation was this thread and the conclusion is that the Mascot report might need a bit of re-wording.

So that we don't have to go through this again in the future it might also be a good idea to add a few words to the phasecal building block article. Maybe after the last sentence: "A value of 1.28 will correct the inherent software error of 2° that arises from the delay between sampling voltage and current" we could add something like: "this is equivalent to an additional current lead of 2°".

Robert - I'll probably go down the route of doing an initial calibration of PHASECAL using the immersion heater - using my target sketch which is integer maths rather than floating.  Ill then tweak the values of the PV and house so that they represent a mid point in there loading.  That's going to be a guesstimate from the measured.  I will then fine tune using the PV meter values (its the best I have - don't know how accurate but its what I get paid on).  I do an initial instant, then a daily, and then one over the week.  My setup with incorrect PHASECAL values is within 1% on daily totals.  I need some good sunny days for that so ill do that on a better days its too cloudy today.
Once I have the calibration settled I will look at setting up a variable PHASECAL  sketch and see if I can correct the inaccuracies on low and high loads.

PHASECAL building block article
At the end the reference to 2° and 1.28 should be removed its confusing and only correct under the right conditions.
It would be better if it stated that the phase value will change dependent on the voltage and load and refer back to the CT and VT testing articles.   I don't know whether it would be possible to redo the CT testing and use the latest burden resistor value and also do more measured points at the low end where we are measuring current most of the time.
Setting a good value for PHASECAL should be the starting point in a Calibrating article.  It should make it clear it will change dependent on Cycle time, ADC speed, voltage, current load and whether you reading 1, 2, 3 CTs.  Its hardare and software dependent also.  A tough article to write and no loose the audience. 
I'm not sure about Robins suggestion that we just ignore PHASECAL and remove it from the maths.  However we might as well if someone is just going to use a standard number of say 1.7 or 1.28.

Why are people talking about different and better CTs on this thread its off subject.  
Start a new thread - a better CT wont help in selecting the correct value for PHASECAL.
Ill read it though - I could fit circular none clip CTs without interfering with my meter it has a separate 100A circuit breaker to split PV and house circuits.  It would have to fit in with the standard emonTX hardware. - don't reply to this here.

I don't know whether it would be possible to redo the CT testing and use the latest burden resistor value and also do more measured points at the low end where we are measuring current most of the time.

Keep in mind the results would really only be strictly relevant for the exact CT you did the tests on.  If you bought 5 identical CTs you'd potentially get 5 different graphs for phase shift Vs current.

If you bought 5 identical CTs you'd potentially get 5 different graphs for phase shift Vs current.

Probably true - provided the phase shift shape is similar then it wouldn't matter.

Here's some data I gathered a while back.  These are not the CTs you're using, so don't use the numbers.  My intention is merely to show the variation between "identical" CTs.  I tested 6 CTs, 2 identical instances of 3 different models (20A, 50A, 150A). 

So for example, the dark blue diamond and light blue X are identical CTs.  Ditto for the pink square and the maroon asterisk.  And finally, the yellow diamond is identical to the brown circle.

At the end the reference to 2° and 1.28 should be removed its confusing and only correct under the right conditions.
It would be better if it stated that the phase value will change dependent on the voltage and load and refer back to the CT and VT testing articles.

Ian, you need to take a step back and re-read what has been posted before as you keep saying the same silly thing. Robert has made it abundantly clear that the value of 1.28 is simply to compensate for the ADC delay between reading voltage and current. This is a constant, it is not dependent on voltage or load.

Setting a good value for PHASECAL should be the starting point in a Calibrating article.  It should make it clear it will change dependent on Cycle time, ADC speed, voltage, current load and whether you reading 1, 2, 3 CTs.

The phasecal building block article was written to explain how PHASECAL works in the standard emonLib. This library measures one CT at a time, with a fixed cycle time, and standard ADC speed. You can't apply it to methods used in other sketches.

Martin - I'm not silly and not wrong.

The section is headed "Theoretical values for PHASECAL" and does explain the shift between the sampling points based on a nominal cycle time.  However it then fails to mention that PHASECAL then needs to take into account the phase shift between voltage and current which does vary.

My emonTX with one standard CT was giving an ADC time of 112µs and a cycle time of 399µs and calculated a PHASECAL which is neither 1.28 or 1.7

There is nothing constant about PHASECAL - it depend on the hardware, voltage and current its measuring
It applies to standard and none standard sketches.  Its just a way of dealing time based sampling and dealing with the phase difference.

I give up - anybody else want to have ago at trying to explain this to Ian?

My emonTX with one standard CT was giving an ADC time of 112µs and a cycle time of 399µs and calculated a PHASECAL which is neither 1.28 or 1.7

Those numbers sound about right for FP maths.  Each of the analogRead() statements takes a little over 107uS, so that's arpound 220uS for each pair of V& I samples.  The rest of the time around each loop is taken up by all the FP maths which follows. 

The purpose of the PHASECAL adjustment is to phase-align the V and I sample streams.   It does this by calculating the voltage level at a given fraction of the way between the two most recent voltage samples.  If the absolute length of each cycle were to change, then so would the calculated value.

The optimal value of phasecal appears to be dependant on many factors including:

- the voltage and current sensors that are being used;

- the relative location within each loop of the V and I sampling commands;

- the absolute duration of each sampling loop.

When using analogRead(), there is much more scope for variability than when using low-level commands to control the ADC.  By having a fixed number of sample pairs per time period, the repeatability should be much improved.  Once the optimal value has been found, a well-constructed program of this type should be immune from further changes to the content of each loop, providing the hardware doesn't change.

Hope this is still on-topic ...

Interesting discussion and I have learned a lot from this. While thinking the subject two questions come repeatedly into my mind.

If and when using test method to determine PHASESHIFT, how much is it depending on:
- distance and wiring (mm2) between measuring point and the calibration load ?
- loop sample frequency (e.g. measured as degrees per "outer" loop) ?

Petrik:

I doubt you could measure any influence from the wiring. The cable will surely add some resistance, capacitance and inductance but the change that these make will be infinitesimally small compared to a normal load.

But the loop sample frequency does of course make a difference - because PHASECAL is the coefficient into the interpolation/extrapolation formula, and if the timebase changes, PHASECAL will need to change in proportion. The equation is in emonLib, or read Explanation of the phase correction algorithm

Ianjm:

"A value of 1.28 will correct the inherent software error of 2° that arises from the delay between sampling voltage and current."
I think that sentence states exactly what "the right conditions" are. I can't see any mention in that article of the practical effects of the transducers, so it would be quite misleading to mention them at all.

If you can demonstrate the exact difference that a fixed mean value of PHASECAL makes compared to the optimal value (presumably got from a two-way lookup table) then I'm sure the community would be willing to listen and take it on board. In the meantime, my feeling is that with normal household loads that have power factors reasonably close to unity, the difference will not be great. It would of course be a different matter if a principal load had a very poor power factor, in that case the difference could will be significant.

It would be nice if our energy monitor always agreed exactly with the tariff meters, but being realistic we can never achieve that without the resources that the meter manufacturers need to have at their disposal in order to meet the relevant international standards. You personal energy monitor can however provide a wealth of data that many users value, even if it is not accurate to better than a few percent. I think you have done well to calibrate yours to within 1% of the tariff meter, and congratulations are due.

concerned about the phase changing with load, then I think you have to aim to set it as close as you can under the conditions that prevail (not sure how to word this) for the largest quantity of energy use - or maybe that should be "at the current you're most interested in"

I suspect there's quite an interesting optimisation problem hiding in there.  From the report it looks like you could get up to about 2° of shift depending on where you are on the current curve (on the CTs I use it's quite a bit smaller, but the shape is basically the same... the phase error tends to increase as the current backs off).

At my house, and I suspect it's fairly typical, big loads tend to be very close to unity PF (mostly heating elements).  The only time I see poor PF is on smaller loads, but I have several of them that run 24x7, with a moderate reactive component, and quite small active component.    So depending where you choose on that graph (or how much current you run during the calibration process) you'll  end up with a small phase error on the big resistive loads, or a small phase error on the smaller reactive loads.

But a small error on the big resistive loads makes hardly any difference to the power calculation.  The small error on the reactive loads can make a significant difference to how much gets counted along the real axis.  In absolute watts terms, it's still pretty small, but if it's something that runs 24x7 that difference can start to accumulate.

I suspect (but haven't proven) that you're better off doing the calibration at fairly modest current levels, so that you're down towards the left hand end of that phase-shift Vs current graph.   Thoughts?

Power factor correction on those small loads? That would reduce the circulating vars, reduce current and hence the losses in your wiring. Not that you're likely to notice though...

Interesting comments thanks (I've been away for the weekend)

Although my emonTX is giving figures within 1% this is for the daily KWh on the PV circuit when compared to my PV tariff meter (I don't have an export meter).  At low values the PV circuit reads high and at high values it reads low.  I assume that the House values are similarly affected.  The way I calibrate evens out the errors to get a matching KWh reading for the day (my final calibrate is done over a week and it was only a small tweak)
I hope that I can do better when I recalibrate my emonTX (3CT, integer maths using CT, CT, CT & V) with better empirical PHASECAL values.  I will try and introduce some code to adjust the low and high end to be more accurate.

Calibrating the Grid and Hose CTs will be a challenge - the house is generally low power most of the day except for when they have large loads from ovens, microwaves etc.  They are both complicated by having the immersion heater dump load running through them.

Ill post my progress on another thread - this one seems to have run its course.
Thanks everyone for your comments & sorry to those I exasperated 
 

Although my emonTX is giving figures within 1% this is for the daily KWh on the PV circuit when compared to my PV tariff meter

Unless your grid manager/inverter is making use of fairly recent German standards (that get the inverter to inject some reactive component) I would imagine your inverter is producing only active power.  If that's true, then your measurements should be pretty insensitive to phase errors.   The source of your current inaccuracies may lie elsewhere.  But as others have said, 1% is probably about as good as it gets.

Calibrating the Grid and Hose CTs will be a challenge - the house is generally low power most of the day

And if it's like mine, you'll probably find it's those loads that have a poor PF.   That's why I prefer to calibrate my phase errors at fairly low current levels.   For my 20A CTs, I calibrate them at 2A for example.   Because I clamp each breaker, rather than the whole house, each one can be exposed to quite low background loads for much of the day.

Although as you can see in the attached graph, with the CTs I use it doesn't make a massive difference.... the lines are pretty flat.  These CTs are the 333mV RMS type with built-in burden, so not really suitable for emonTX use, but they do show the classic shape exhibited by most CTs.

Unless your grid manager/inverter is making use of fairly recent German standards (that get the inverter to inject some reactive component) I would imagine your inverter is producing only active power.  If that's true, then your measurements should be pretty insensitive to phase errors.

Measurements that I've taken of the output from various inverters show that the current profile is far from sinusoidal (i.e. following the voltage with PF = 1).  On a number of occasions, I've suggested that other people may wish to take similar readings for their own systems, but so far no-one appears to have done so. 

My RawSamplesTool_4ss_2 sketch is ideal for this purpose.   Just load it up, clip your CT around either of the inverter's output leads, and press "Go".  I confidently predict that your waveform's profile will appear anything but sinusoidal.  It will, however, be roughly in phase (or anti-phase) with the voltage signal.  The resulting waveform will be displayed in low-res form on the screen; the full-res version is sent to the Serial Monitor.

Any takers this time around?  Probably best for someone to start a new thread for any such results.  I thought I'd already done so, but can't find it now ...

Interesting.  I missed that thread.  I posted the output of my inverter a while back here:

http://openenergymonitor.org/emon/node/2475

just to show how the consumption of what I produce tends to all happen at the peaks.  But you can see there my inverter output looks pretty sinusoidal.  I guess it depends on the make.

[Edit] Or maybe it depends how close the inverter is to its max output?  Mine was only about 1/3 of the way there in that trace.  I'll do a recapture next time it's really belting out some current.

[Edit2] I'm only able to get sine waves out of my SolarEdge.  This article lists various techniques they use to generate their sine wave and which manufacturer uses which:  

http://www.homepower.com/articles/solar-electricity/equipment-products/h...

[Edit3] In these parts, AS4777.2 defines the power quality required before you can connect your inverter to the grid.  Copying the exact spec might put me in violation of copyright, but it's pretty tight on harmonic content.

dbc: Interesting.  I missed that thread.  I posted the output of my inverter a while back here:

http://openenergymonitor.org/emon/node/2475

Sorry, dbc, I missed that one.  That's exactly the kind of waveform profile that I've seen from my own Nedap inverter and some others that I've tested.   I must re-post my traces onto that thread.

Our Nedap has recently had its innards replaced for some reason at no charge to us, and a fresh guarantee was supplied at that time.  It will be interesting to recheck the output waveform, as the specs that such inverters have to meet may well have changed since our original unit was manufactured (in 2011).

That's exactly the kind of waveform profile that I've seen from my own Nedap inverter

Are you referring to the red trace or the yellow trace?  The red trace is what's coming out of the inverter, and looks pretty good to me.   The yellow trace is what gets sent out to the grid, after all my appliances help themselves to the peaks.  That's not my inverters fault.

Are you measuring your line as it comes out of the inverter,  before any of your consumers have had a crack at it?