You are a star @Robert.Wall
Any thoughts on the flashing?
I have only the ‘shop’ programmer, and it just works. You do need 5 pins - all except 3.3 V. (i.e. GND, 5V, TX, RX & DTR) DTR is actually used as the ‘Reset’. Beware, RX & TX are swapped over on the pcb, so the pin labelled “RX” is looking for the RX line at the other end - yes, it’s opposite to the normal convention.
I don’t have DTR so I would have to flash the emonTx with an Arduino but it’s a bit academic at the moment.
Scale starts at 0 to 200 Ohm, is this OK?
That’s not what I meant - the open-circuit voltage needs to be such that you’re not going to take the input pin outside the supply rails, and with any significant current behind it. You’ll need to carefully read the meter manual / spec. sheet to find that information. My multimeter tests resistance and continuity at < 0.35 mA and < 0.5 V, so the current is within the limits of the protection diodes in the ADC input, and neither current nor voltage is a concern from the point of view of damaging the input.
I’ll check the meters manual. I have the Eagle file open. Am I checking for continuity between the ADC0 pin on the '328 to somewhere and if so where? I can see where the pins for ADC1 to ADC6 go but not ADC0.
You need to check from the burden for the suspect input back to the ADC input on the processor. CT1 is ADC1 - pin 24. You should see the 1 kΩ series resistor R19.
1 Like
Good news CT2 to CT4 look to be fine.
Do the same raw samples go into the two calculations, or does it calculate one from one set of samples, and the other from another set of samples? Assuming the same samples are used, I’m struggling to get my head around how real power can end up larger than apparent power.
It just means you haven’t calibrated the hardware.
Therein lies the problem. It’s the phasecal interpolation that changes the amplitude as a side effect. The rms voltage calculation uses the raw samples, the average power (of necessity) uses the phase shifted and amplitude-changed extrapolated samples. I’m sure at some point I changed, or proposed a change, to correct this, and I’ve put a correction into the new emonLibCM and into the 3-phase PLL sketches (both being tested).
I think all the things that can be done better in emonLib that don’t break backwards compatibility have been done, but there are actually quite a few things remaining that could be done better, but they break backwards compatibility. For example, swapping the order of reading voltage and current means much less amplitude distortion that gives this problem in the first place, but it dramatically changes the value of PHASECAL.
@GeorgeB
Please don’t make rash comments like that when you apparently haven’t checked your facts. If you study the emonLib code to see how the calculations are done, and study the ‘Learn’ section to see how the phase shift is accomplished, you’ll be better informed.
Interesting, that’d do it. Thanks for the explanation.
@Robert.Wall so now you are saying calibrating will not correct the PF i.e. realPower being greater than apparentPower?
I’m saying that if the amplitude change produced by the extrapolation is enough to survive rounding effects in the calculation, then the use of two different values for voltage may give rise to the situation where, given sufficient significant figures, a power factor greater than unity will be reported.
The problem has only become apparent with later models of the SCT-013-000 as the required value of phasecal has risen, to around 1.85 with the latest batch that I tested.
@Robert.Wall
If you remember CT1 on my emonTx is dead.
CT2 to CT4 appear to give accurate realPower figures but now I have started flashing my own sketches it appears it will not give current or apparentPower.
I didn’t check the CT1 burden resistor back to Arduino pin as I could only find a basic user manual for my meter and I couldn’t be sure that I wouldn’t make matters worse.
The fact that current and apparentPower for CT2 to CT4 are incorrect does that suggest the problem is something more than a bad track to CT1 burden resistor?
I’m confused though how it can work out realPower for CT2 to CT4 but nothing else.
ct2.Irms etc is a valid call, right?
I can’t immediately see which sketch you are using, so I shall tell you how to find out what the format is for using emonLib.
First, look at your sketch. Somewhere near the top, and certainly above setup( ), you’ll see a line like
EnergyMonitor ct1, ct2, ct3, ct4;
This defines instances of the class “EnergyMonitor”, calling them “ct1”, “ct2”, etc.
Now the class has “methods” (in reality functions, that do things), and variables; these are defined in the emonLib header file emonLib.h. You may only use those declared as “public”.
To set up and initialise the class instance (ct1 in this case), in setup( ) you do
ct1.current(1, Ical1); and
ct1.voltage(0, Vcal, phase_shift);
and then in loop( ), to calculate the rms and average values of those inputs you defined in the initialisation, you do
ct1.calcVI(no_of_half_wavelengths,timeout);
When you’ve done that, all 5 variables listed as “public” are available to you: realPower, apparentPower, powerFactor, Vrms & Irms, and you access them as you say with the syntax
ct1.Irms
(But it’s not a “call” to a method/function/subroutine, you’re simply accessing the variable.)
Therefore, “ct1” specifies the instance that you associated with c.t. channel 1 in the initialisation, and “Irms” picks out the variable associated with that instance.
You can do “ct3.apparentPower”, “ct4.powerFactor”, or if you called the class instances Tom, Dick and Harry, you could have Harry.Vrms & Tom.realPower.
1 Like
@Robert.Wall yes I shouldn’t really have used the term “call”.
I have used the true “Serial only” (short sketch) and 2.9 with RF disabled (big sketch) and results are the same.
Is it possible for the sketches to work out realPower without having correctly calculated Irms?
No. The calibration constants you give it in
ct1.current(1, Ical1); and
ct1.voltage(0, Vcal, phase_shift);
are used in all the calculations - Ical in current, Vcal in voltage. In turn, current and voltage are used to calculate real and apparent power, but phase-shift is only used for real power.
Ok I’ll check the sketches again tomorrow.
I need to do some calibration as I notice CT2 gives minus 90W with no load. When I add 50W load it correctly goes to minus 40W.
I have tried similar calibration to the figures I have for the emonTx shield but I’m not getting similar results.
You could try one of calypso_rae’s test sketches - https://openenergymonitor.org/forum-archive/sites/default/files/RawSamplesTool_4ss_2.ino_.zip
If you run this against ct1 (set the correct voltageSensorPin = 0 & currentSensorPin = 1),
with no input (but a plug inserted into the socket) the current samples should be a straight line down the middle. (Plot the numbers on a spreadsheet if it’s not clear, or you want more detail.)
If you now short the burden to GND and then to 3.3 V, you should see the current go to the appropriate extremes. If those tests pass, it would seem to indicate that the input track is not broken, and the fault lies elsewhere.