Since switching to the continuous firmware I’ve found the Grid power drops to zero for one or occasionally 2 samples several times an hour before returning when its measuring between 9 and 10Kw whilst other inputs are unaffected. I’ve also noticed a large difference in reported values compared to the discrete sketch despite using the same burden calibration values and calibrated Vrms at similar power levels.
Comparing the hourly data from my power provider against the usage when the fault is occurring reported in MySolar I see that:
Continuous Sketch reported 8.3Kwh, actual use 12.12Kwh
Discrete Sketch reported 11.7Kwh, actual use 10.79
I can understand the differing value may be down to PF and lack of calibration, but its underreporting by a lot and the dropping down to zero is an obvious fault that goes away if I revert to the Descrete Sketch.
I’ve filed an issue on Github for this as its easily repeatable.
The RX line on the EMONTX is not connected so this can’t be affected by any incoming serial commands
How? Did you use one of the example sketches that you downloaded with the library? I suggest you try one of those - the documentation explains more fully, the “min” one uses the absolute minimum number of options that give a working demonstration, while the “max” one gives an example of every API call.
There is a problem with JeeLib, that didn’t show up during testing, which has caused lock-ups and resets - is it actually resetting and the zero value is a result of that?
The calibration for voltage and current should be the same, but the phase error correction values are substantially different, and using the values for the DS sketch will give an error in the real power value reported.
Are you implying that you are using the serial connection for the data output?
If you are then you don’t need to transmit the data using the RFM and you can comment out all the RFM functions beginning RF12_. That should remove any difficulties arising from JeeLib.
I’m using the sketch from GitHub - openenergymonitor/emontx3: EmonTx V3.4.x Hardware and older discreet firmware, see EmonTxV3CM repo for latest and the only changes are to the reporting rate which I’ve doubled as I use it elsewhere for load shedding, the calibration and I’ve commented out with a couple of slashes 'DEFINE_RF ’
Would the jeelib reset cause the serial output to become zero only only the first power value? I’m using all outputs via serial, and only CT1 is reset to zero, the others and Vrms don’t drop, and the MSG value reflects the correct number of samples since the last manual reboot.
Is there an easy way of working out the rough phase error such as adding 2 x 3Kw water heating elements and then changing calibration until a peak value is reached? Due to the other half working from home during the current lock down I can’t turn everything off right now
That’s the Discrete Sample sketch. Do you mean the CM one linked from there? If so, that’s Trystan’s sketch and it’s flaky. I think the problem is around all the if... statements, some are trying to force the CM library to work like the old one - which was never intended as they work in a completely different way, and some are doing unnecessary switching that’s done internally in the library anyway.
If ENABLE_RF is not defined, it can’t be JeeLib.
If you’re using the UK a.c. adapter and the SCT-013-000, then the values in the demo sketch should be close. If not, then I’ve really no idea what the phase errors of what you have might be - unless they are on a data sheet somewhere. It should be possible to convert the old PHASECAL to the new, but I’ve never actually done the maths.
If you can’t shed your reactive loads, can you make a temporary test rig with (say) 4 turns of wire through the c.t. and one 3 kW resistive load - that should give you the 12 kW you normally see - and adjust the phase calibration to that? It won’t change between moving the c.t. from there to it’s proper position.
If you can’t do it empirically, let me know the value you had for the DS sketch and I’ll see if I come up with a sensible number for the CM one.
Yes the linked sketch. I’ll take yours and see if I can start from scratch. I was trying to keep things as standard as possible having been burnt at upgrade time a few times in the past.
I am using the UK AC adapter, and the standard setting isn’t far away, usually within 10 volts or so, and we are nominally 230V here rather than 240+ in the UK. In reality the voltage sits closer to 240 unless its big load time. I’ll take the Hot Water CT, and do the 4 turn thing before adding it into the grid input, that should account for the differing load resister phase shifts. I’ll also measure on my meter what the value should be and do the maths to get it somewhere near. Its not practical to get to the grid CT.
Once I’ve done all that hopefully the dropping to zero fault will be gone 
The problematic condition only occurs once a day under specific conditions so it’ll take a while
An emonTX is outside of the emonCMS/emonPi update loop so any changes you make are ‘safe’.
Specifically, you must physically connect a programmer and computer to the emonTx, open the source file in the IDE, compile and upload for any change to happen.
I’ve created a strip down sketch after spending a while calibrating with 5 turns of wire on a CT. CT1 has a 22Ohm burden and the rest have 120Ohm burdens now. I’ve done the calibration using CT1 with 5 turns and CT3 with a single turn, I haven’t worked on CT2 and 4 yet so I’ve just copied the values. I’ll likely need to visit this again as my main meter has a blown current measuring fuse. Calibration has been done using a combination of 3 incandescent light bulbs and a resistance heater.
Can you give the sketch below a quick check in case I’ve missed anything obvious?
#include <Arduino.h>
#include "emonLibCM.h"
// calibration values
float i1Cal = 93.16; // 22 ohm burden default 90.91
float i1Lead = 4.8; // was 3.0
float i2Cal = 17.15; // 120 ohm burden
float i2Lead = 9.8; // to be calibrated
float i3Cal = 17.15; // 120 ohm burden
float i3Lead = 9.8; // this one calibrated
float i4Cal = 17.15; // 120 ohm burden
float i4Lead = 9.8; // to be calibrated
float vCal = 266.08;
void setup()
{
Serial.begin(115200);
Serial.println("\nEmonTx v3.4 EmonLibCM Continuous Monitoring Downstairs V1");
EmonLibCM_datalog_period(4); // period of readings in seconds
EmonLibCM_SetADC_VChannel(0, vCal); // ADC Input channel, voltage calibration - for Ideal UK Adapter = 268.97
EmonLibCM_SetADC_IChannel(1, i1Cal, i1Lead); // 22Ohm Burden ADC Input channel, current calibration, phase calibration
EmonLibCM_SetADC_IChannel(2, i2Cal, i2Lead); // The current channels will be read in this order
EmonLibCM_SetADC_IChannel(3, i3Cal, i3Lead); // 90.91 for 100 A : 50 mA c.t. with 22R burden - v.t. leads c.t by ~4.2 degrees
EmonLibCM_SetADC_IChannel(4, i4Cal, i4Lead); // 16.67 for 100 A : 50 mA c.t. with 120R burden - v.t. leads c.t by ~1 degree
EmonLibCM_ADCCal(3.3); // ADC Reference voltage, (3.3 V for emonTx, 5.0 V for Arduino)
EmonLibCM_TemperatureEnable(false);
EmonLibCM_Init(); // Start continuous monitoring.
}
void loop()
{
if (EmonLibCM_Ready())
{
Serial.print(" V:");Serial.print(EmonLibCM_getVrms());
for (byte ch=0; ch<4; ch++)
{
// Serial.print(", P");Serial.print(ch+1);
// Serial.print(", I");Serial.print(ch+1);;Serial.print(":");Serial.print(EmonLibCM_getIrms(ch),3);
Serial.print(", W");Serial.print(ch+1);Serial.print(":");Serial.print(EmonLibCM_getRealPower(ch));
// Serial.print(" VA=");Serial.print(EmonLibCM_getApparentPower(ch));
// Serial.print(" Wh=");Serial.print(EmonLibCM_getWattHour(ch));
Serial.print(", pf");Serial.print(ch+1);Serial.print(":");Serial.print(EmonLibCM_getPF(ch),4);
delay(10);
}
Serial.println();
delay(10);
}
}I can’t see anything wrong with that. You only need to define the c.t’s that you’re using, and if you use identical c.t’s and burdens, then the lead angles should be nearly the same. It’s the high value of burden on channels 2-4 that makes the phase error so much different from ch 1 (even with an identical c.t.).
You can have decimal seconds for the datalog period, so if you’re working into emonCMS and particularly the timeseries database, you want that to be just less (by I suggest 40 ms - 2 cycles) than the database period so that you don’t store nulls if the data arrives a little late.
Are you referring to GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware) ?
Yes, I was. Kevin is discussing the CM sketch, but in fact he linked to the old default DS sketch where, in the readme, the CM sketch is mentioned and linked:
Note: The default EmonTxV3 firmware is now the EmonTxV3CM Continuous Monitoring firmware,
Thanks for the reply, it’s testing ok so far albeit at a different power reading due to the recalibration. I’ll monitor it for a few days to check all is well, I’ll also do a quick recalibrate once I have a new meter fuse when the shops are allowed to open again.
@Robert.Wall one further question. When calibrating a emontx for use with a bunch of micro inverters, is it just a matter of calibrating with a resistive load, checking the current and voltage agrees with a meter and then getting the power factor until it’s as close to 1 as I can get before reversing the CT? The reason I ask is that the power factor seemed worse than expected measuring the solar, although it was late in the day and the micros were at around 40% output. Switching to a resistive load of 3 light bulbs and a heater gave a PF of 0.9997, and a single 60W bulb read 60W
Yes, that’s the way to do it. In the long term, the meter to agree with is the one that generates your bill, because by definition that is 100% accurate, even though it might not be. That’s unless you have access to something that can be proven better.
Depending on the c.t. and v.t. that you use, the difference in the phase errors - which is what we’re interested in - will depend upon the actual voltage and the actual current, because the individual errors for both depend on the value of the measured quantity. So ideally, you calibrate at your “typical” system voltage and load current (whatever ‘typical’ means). If look at the reports in ‘Learn’, you can see the measured values and how they change.
I’ve heard it said that some inverters can adjust their power factor to correct your overall power factor, but I’ve yet to see hard evidence of that. It would be in the power company’s interests if they did that, because they’d deliver (or accept) the same power with less current.
Here’s a shot of the output from 42 Enphase micros. 10 of them are M250s, the rest are M215s.
Here’s a zoomed in shot of the PF going out the window as the PV output drops toward zero:
That explains much - thanks! I’ve got a similar setup, and the panels I noticed the bad PF on never get anywhere near their rated output at this time of year. Once summer returns I’ll be claiming on the solar panel warranty assuming I’m right and they don’t meet the guaranteed output at their current age when the sun is overhead again.
Interestingly one of my 2 non optimal strings currently has pf of 0.9298 and the other is 0.9949 so I think something is currently amiss. The fault moves when I switch the emontx inputs over so its either the CT or the Inverters. Looking at the 15 minute per panel output from the Envoy suggests the inverters are OK so I’ll take a look at the CT.
@Robert.Wall the latest Enphase IQ Series Micro Inverters have setable PF at the request of the utility provider meaning they can be downgraded at their request. There is also provision in the spec in Australia / New Zealand for utility control of the whole system IIRC.
You got it! Happy to help. 
One further question. How are your panels ageing compared to the published 25 year degradation? Mine are around 4 years old and noticeably below the published spec
I haven’t kept track of the drop in performance, so don’t really know what the actual value is.
Here’s the “lifetime” energy production from my system. I didn’t have an Envoy until 30 Dec 2015,
but my system was installed in March of 2013, so not all of the production has been “recorded.”
The three micros denoted by the darker blue shade are ones that have failed and been replaced.
The rightmost one in the second row has read low from day one, yet has been a steady producer.
It just doesn’t produce as much as the others. I figure the PV module was “bad-out-of-the-box,” as
it gives the same results when the inverter is swapped with others in the system.
Power production on 30 July 2018:
Power production today, 25 Apr 2020:
Today’s power values are higher because the ambient temp is 70°F vice the 90+ it was
in July of 2018.
The roof mounted part of the system is tilted at ~17° the ground mounted part at ~25°
As you can see, the Canadian solar values are fairly consistent, yet there are a few that perform better than the rest.
What I found surprising was the roof mounted Talesun 240s have always outperformed the
Siliken 255s. (also roof mounted) Some of the CS235s have outperformed the Siliken modules too.
Output as recorded at pvouput.org:
As can be seen, the annual totals from 2016 to 2019 have been fairly steady.
The 2103, 14 and 15 values changed because I expanded the system during that timeframe.
In '13 I went from 4 to 8, then 16 panels. '14 saw the addition of 12 more, then another 12 in 2015.
Thanks very much for that, I’ll have to wait for summer now which is a few months away and in the meantime will attach a temperature sensor to the back of one of the panels so I can provide specifics on the panels performance. The maximum they are reaching currently is between 160 & 165Watts which is low.