EMONTX, Continuous Firmware, 120Ohm Burden Resistor Phase Error

I use an EMONTX V3 to monitor my Solar Array which is split into 4 Micro Inverter Strings with a CT on each. All inputs have a 120Ohm Burden and I use 8 turns inside the CT on 2 of the 500W Max strings, 4 turns on the 1Kw Max String and 2 on the 2 Kw Max String. I’m about to move to the Continuous Firmware. In the Default sketch it has i4Lead set at 1.0 which is for the 4th input which has a 120Ohm Burden Resistor from the factory, whereas the rest are set at 4.2 for the standard 22Ohm Factory Burden Resisitor.
Should I set i1Lead, i2Lead and i3Lead to 1.0 too, or is there a cable and manufacturing tolerance issue I need to calibrate for?
I’ve read the documentation in Building Blocks which suggests the phase error is worse with the YHDC CT as the burden value increases yet the sketch suggests otherwise?

No, your concept of phase correction is wrong there. It isn’t phase correction of the c.t. alone, it’s the difference between the phase errors of the c.t. & v.t.

Yes, the phase error of the YHDC SCT-013-000 is indeed worse with the higher value burden, and it varies more over the working range too, but it’s closer to the phase error of the v.t., hence a smaller correction is needed.

Your IP address suggests you are in NZ, so unless you’re using the “shop” a.c. adapter, all those values might not be correct anyway, so you should check and adjust the phase correction to suit.

Thanks for the clarification, I’ll set them all the same and see what results I get. I’ll also verify it with a load of conventional light bulbs. I’m in NZ and using the UK 3 Pin adapter from the shop with a travel adapter.
My second EMONTX will likely need a lot more configuration work as it has 4 different burden values!

Note that a c.t. – any c.t. – is happier when under the least load, which, as it’s a current source, is when the burden is closest to a short-circuit. If your wire sizes allow, it’s better to obtain the voltage you need for the ADC with a multi-turn primary and a lower burden than it is to increase the value of the burden.

That makes sense, its why I’ve got multi turn primary’s in this part of the system. Out of interest can you give me a guesstimate of the difference in accuracy between 2 turns and 120Ohms or 4 turns and 60Ohms.
Also now I’ve just installed the continous firmware I note it seems to have a 10Second reporting rate, is there any practical way of increasing this? My existing discrete sketch on the other EMONTX updates every 5 seconds and I use it for load shedding to protect the main fuse during a free period when the Dishwasher and Tumble Dryer elements kick in.

Have a look at the test results in ‘Learn’ for the YHDC c.t. If you’re using that, they’ll be a good guide. Otherwise, all I’d say is the errors will be smaller, but by how much is anyone’s guess.

emonLibCM will work down to below 1 second. All you need do is tell it the interval you want to use. If you download the zip file from EmonLibCM - Version 2.2.2, in it is the full documentation that gives details of all of the API.

Thanks, If I understand correctly the library works continuously and reports the average value since the last report? So currently its the average power for the last 10 seconds and if I change it to 5 seconds reporting it will be the average power for the last 5 seconds?
If that’s the case I’ll change the EMONTX handling the grid which handles load shedding to 5 seconds and leave the solar one which is more for logging at 10 seconds

Yes. There’s no inherent reason that you can’t have different inputs reporting at different rates, but there’s going to be a lot of work to change the library to do it, and a lot more work changing the rest of the OEM systems to handle the change. Ugh! I can think how I might approach it, but it’s very messy.

If emonCMS could offer to accumulate and average over a set of n readings, that would be an easy(er) way to do what you want.

The only practical way not involving changes would be to report every 10 s but log every 5 s. You’d be back to “Discrete Sampling” for that feed - but the sample would be the average of 5 s out of 10. That’s a lot better than 200 ms out of 10 s.

Apologies, looks like my post didn’t mean what I was thinking. I’ll change the whole EMONTX, from 10 seconds reporting to 5 seconds reporting with the EmonLibCM_datalog_period value. There isn’t any point in creating work and non standardisation especially as I’m not a programmer by trade.

Don’t worry, I understood what you meant - but I added that about changing the interval for each input by way of explanation. I’ve no intention of implementing it, if only because the whole system is designed around each node reporting everything at the same time. It’s only after the data hits emonCMS that different reporting rates can be handled easily.

Incidentally, the 10 s default descends from emoncms.org, where it’s done to prevent any one user from hogging the system. For your own server (read emonPi), the choice is yours, and will be ruled by storage capacity as much as anything.

As a rule I avoid anything not hosted locally as historically online stuff hasn’t been that reliable with regular packet loss on my local Internet connection. Fortunately times have moved on and I now have Fibre, but I still stick to my own hosting on a dedicated PC alongside OpenHAB.

The new library looks good so far, but I won’t know if the calibration is the same as the old descrite sketch until the sun appears, and today its rather shy. With the previous sketch and 2 Enphase M215 Micro Inverters being driven flat out by oversized panels EMONCMS reported 229 - 230W Per Panel, and the micro inverters themselves reported 229W. That’s with 8 turns and a 120Ohm resistor which seemed pretty good. It’ll be interesting to see whether the overnight ghost power has changed too

The amplitude calibration for current and voltage is the same as the old emonLib. However, that did introduce a small error due to the way real power was calculated, so there might be a discrepancy in the power due to that.

Put it this way, I can see the deviation between emonLibCM and my optical pulse count vary, depending on the load. Almost certainly, this is due in the main to the phase error of the c.t varying with the current. The library does its phasecal correction in a way that’s amenable to making the correction current-dependent, so one day I might add that feature. But don’t hold your breath.

I’ll watch from a distance :slight_smile: When they installed the smart meter for my solar they installed a 3 phase meter and sent the grid connection through it twice, once forward and once backwards meaning my pulse output is useless. They do things a little differently over here!
Given a choice I’d prefer optical pulses

The trouble is, light doesn’t flash backwards :laughing: so you can’t tell the difference between import and export - even if your meter does flash on export (which most don’t, they remain steady on).

Very true!
Could I draw on your expertise one more time please - I’m doing my final EMONTX which has a mixture of Burden Resistors and to do this properly I need to turn the whole house off which I don’t have time to do right now. Could you give me a guesstimate on Phase Correction Values for resistances of:
36 Ohms - I’m guessing this should be around 3
110 Ohms - as this is close to 120 Ohms I’m guessing around 1.0
170 Ohms - I’m guessing this heads further towards negative than 1.0 so maybe 0.7?

I really wouldn’t like to say, as I’ve never measured a recent c.t. with values other than 22 Ω and 120 Ω.

No worries, I put in my guesstimates and I’ll do it more accurately when I’ve got chance to pull all the house fuses and experiment with resistive heaters and kettles. As 2 of the 4 inputs are water heating elements, and one of the others is a HVAC unit it likely doesn’t matter that much. I’ll keep an eye on it during the free hour when everything is running to check its in the right ball park.