Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Puzzled by 3 phase readings

I have an emonTx monitoring the in-coming 3 phase supply at one of the premises I use and am a little puzzled by the readings on one of the 3 phases (L1 Red) which presently has very little load.

The supply to the voltage reference is on the incoming L3 (Blue) phase (because that is what happens to be available on the socket by the incoming supply cables) and that is the one connected to CT1 (P1) input, with CT2 (P2) on L2 (Yellow) and CT3 (P3) on L1 (Red).

However today a heater was added for a few hours and this saw the measured figures on L1 (Red) go negative, so where I had originally placed the CT sensor one way around I came to the conclusion it must have been the wrong way so I have turned it around.

However that means now when the heater goes off the power used on that phase shows around negative 300W - I have checked the current calibration figures in the emonTx_3Phase_PLL_V1.7 firmware and they appear to be correctly showing 90.9 and I have swapped the CT sensor for unused one that I have and the result is the same.

I swapped the CT2 and CT3 sensors around, but that just showed the -300W appear on the other chart.

Is there anything else I should check or can do to try to improve the readings ?

I have another emonTx that I could try, but have not yet done that.

In case in matters I’m using a USB-> serial connection from an emonPi to the emonTx and the Radio is disabled.

One for @Robert.Wall I suspect but firstly, you do have the 3 Phase Sketch installed?

[edit]
Yes I see you do.

Did you go through the full calibration procedure in the documentation for the sketch - because it sounds to me like a phase error in that c.t. It starts on page 6.

Over the years, the phase error of those c.t’s has changed as the manufacturing has changed - and I don’t have access to all those arriving in the shop to be able to test them. It’s certainly true that the early grey-lead ones have different phase errors to the black-lead ones.

Thanks for the response, It seems that had missed some parts of the calibration process and will need to repeat the process when I have suitable equipment available.

So looking at the Calibration instructions for emontx PLL V1.7 I need a little clarification:

I’m not using CT4 so I think NUMSAMPLES should be 45 (for 50Hz system) but I find the notes a little confusing.

I am presuming LOOPTIME should match the PHPFINA fixed interval period used in the emopPi that is capturing the information (i.e 10000).

How close to 1.000 does adjusting the iLead settings need to be ? I had 0.9994 on two and 0.9976 on another and changing the numbers seems to make very little difference.

I had to hunt in various places to find the information on which board I should select in the Arduino IDE (which I eventually found is uno).

In what way is it confusing? You should strive for the best (i.e. fastest) sample rate, hence the maximum number of samples to give the best resolution frequency-wise - with an eye to sampling theory and Nyquist. It’s quite OK to leave it at the default 36 if you prefer.

In fact no, it should be slightly less. If a sample misses its slot in emonCMS, you get a null value stored. If subsequently that point happens to be chosen by the graphing algorithm as a point to be plotted, it’s drawn as a zero value - irrespective of the scale and whether an adjacent point was valid. Many years ago, it was decided (in the face of complaints along those lines) to reduce the time between samples so that no slots would be missed, but occasionally two samples could arrive in the same slot and the first would be overwritten; this being the lesser evil.

I’d suggest about 9.9 s, how much shorter depends on what else the emonPi is doing that might delay the readings on their way into emonCMS. If you get too many nulls in the database, you can shorten the interval a little.

When it’s close to the correct value, it will make very little difference. You’re trying to find the crest of a sine wave, in effect. If you could get a pure reactive load and enough current, then adjusting for zero p.f. would be much more precise. But remember also, the phase errors of both the v.t. and the c.t. are dependent on the voltage and current respectively, so your correction is only valid when conditions are the same as when you set it up.

I cannot explain exactly why it is confusing to me, but its something to do with the wording acround the table and the 3-wire / 4-wire / 3ct’s / 4ct’s.

I still not sure if I should keep trying more tweaks to get the readings of PF to exactly 1.000 or is 0.999x is close enough.

That’s as good as you can hope for. If your system voltage changes, or you do it at a significantly different current, the reported power factor will change quite a bit in the 4th digit. In degrees, you could have about 1° shift in the a.c. adapter from 230 V to 240 V which is well within the normal operating range that I see, and cos(1°) = 0.9998. Add in the c.t. and that will shift another degree between 0.3 A & 30 A; or 4° if you’re using the high sensitivity input.

Is it the absence of separate tables (or extra rows) for a 3-wire system? What happens is with a 3-wire system, the third phase is treated as a neutral and you then have a two-phase system with 60° between phases. Hence the requirement to fit the number of samples into ⅙th of 360° rather than ⅓rd. The numbers are maxima, you can go lower, but ideally you want the maximum you can have per cycle.
I didn’t want to confuse it too much by making the table too big, because 3-wire systems are fairly rare, and being replaced where it’s feasible.