Hi,
I'm using Emonlib on a particle photon , coupled with an SCT-013-005 (1Vout for 5A) in order to detect when the pump of my fuel boiler is on (sor I can measure fuel consumption).
..
emon1.current(1, 5); // Current: input pin, calibration.
..
double Irms = emon1.calcIrms(1480); // Calculate Irms only
But the results seems strange : I get max 34W measured with an halogen bulb of 60W
the gap seems really too high to me to be reliable :-/
...
Re: Sct013-005 , unexpected results
I cannot guess - what current does your 60 W represent?
[Read the FAQ for two reasons - the answer might be there, and you'll see what you need to tell us so that somebody can help you.]
Re: Sct013-005 , unexpected results
I measure 50mV AC with my multimeter , so with 230V , it's corresponding to a current of 0.25A and more or less to the power of the bulb (57.5W computed for theory of 60). The sensor is biased to 1.65V using 2 20K resistor and a 10uF capacitor .
Re: Sct013-005 , unexpected results
How did you measure the 50mV with your multmeter... was it with one end of the CT connected to your mid-rail, and the other end connected to your analog input, and the multimeter connected between the two? Or was it the multimeter connected directly to the CT with no other hardware in sight? Do you have an additional burden resistor on your board, or are you using just the burden resistor inside the CT?
Re: Sct013-005 , unexpected results
The sensor has an integrated burden resistor, and I'm using only this one. I measured the voltage with both end of the CT connected directly to the multimeter. But I will try to measure using the bias voltage too !
Re: Sct013-005 , unexpected results
If you get a different voltage, 50 mV * 34 / 60 or very near to that, at the same place when the CT is in-circuit, it means something has gone wrong with your circuit design and you are "loading" the CT. If not, then my first guess would be that emonLib has not measured or been told the correct value for the reference voltage that the ADC is using, and so it has applied the wrong calibration factor.
The easy fix in this case will be to change the lines in emonLib.cpp where this is done. It is in two places, lines 178 - 182 in calcIrms( ), lines 69 - 73 in calcVI( ), and you need to assign the correct value for your board to "SupplyVoltage".
[What these lines do is if you have an emonTx V3 and you have "#define emonTxV3" in the sketch, it assigns the number 3300 (3300 mV) to SupplyVoltage. Otherwise, it tries to measure it using the internal 1.1 V reference and readVcc( ).]
Also, you might want to change the "1480". That was our best guess for the number of samples it reads in a whole number of mains cycles (I think it was 15 cycles @ 50 Hz, 18 @ 60 Hz), so if your Photon runs at a different speed (and it looks like about 3-4 x faster!) than the Atmel 328P, 1480 will not be the best number to use.
[Edit:]
See http://openenergymonitor.org/emon/node/11292 and http://openenergymonitor.org/emon/node/11309 for others who are experimenting with the Photon.
Re: Sct013-005 , unexpected results
If you work through all the #ifdefs in readVcc() I think the intention at least is to return 3300 for your platform (and any platform it doesn't recognise), so if it doesn't you might want to fix it in there. I'm not sure why the #ifdefs Robert refers to above are outside the routine and the rest are inside... I suspect for historic purposes.
Re: Sct013-005 , unexpected results
I corrected the problem by changing the analog input . By swapping from A1 to A0 on the Photon , I get a good 57W Oo I can't explain why , I will ask on the Photon forum if there's a specific reason to get such a different result...
By the way , I think the Aref voltage is fixed to 3300 in the Emon Photon library available . Concerning the sampling rate that's not so well documented but I think tha sampling time can be modified , so the impedance is changing too. I will do some tests for the best number of samples and post it here.
Re: Sct013-005 , unexpected results
By swapping from A1 to A0 on the Photon , I get a good 57W
That does sound dodgy but I'm glad you got it sorted. When you get to the bottom of that I'm sure the owner of this thread: http://openenergymonitor.org/emon/node/11292 would appreciate a heads-up on what you found (I've linked him back to here as well).
Do you have any over-voltage protection on your ADC inputs? At 1V per 5A your CT could potentially generate some pretty serious voltages. I'm wondering whether there's any chance you over-cooked A1 at some stage?
What are the specs on your boiler fuel pump? You're probably already aware of this but in case not: pumps can draw some big current as they start up for quite an extended number of cycles. I suspect my pool pump is way bigger than your fuel pump, but I'll attach a pic to show you just how bad it can be. Once it's running I think it draws about 5A, and it's on a 20A breaker, so I figured a 20A CT (as in 20A -> 333mV) would be fine. It wasn't... the first few cycles got the IC well and truly clipping. My inputs are +/-500mVpeak max deflection and +/-2Vpeak never exceed. I've now put a 50A CT on it, and things work much better.
Re: Sct013-005 , unexpected results
Just as a guide, a typical induction motor will draw 7-10 times its normal running current when starting up.
Then when it is running, the watts consumed are considerably less than amps x volts due to the lagging power factor.
Re: Sct013-005 , unexpected results
It's called "inrush", if you want to read about it.
Re: Sct013-005 , unexpected results
And power factor (and power of course) varies quite a bit with load. The two pics below compare my pool pump being a pump (~1100W with a PF of 0.89) Vs running on the bench with the impeller removed (~250W with a PF of 0.47). In fact my energy monitor alerts me when it's time to clean the filters and even shuts the pump off when it detects cavitation.
Re: Sct013-005 , unexpected results
I'm aware about motors inrush current , but thanks to remind me to put some protections at the analog inputs :-) The scope screens are indeed explicit ! Oo
But at this time I'm using only an classic light bulb of 60W for thr tests, so a pure resistive load. I will check my A1 input with known voltage and if there's not a sort of functions mix with this pin on the Photon board .
The measured voltage (multimeter) when the fuel pump is on is about 0.15V if I remember well. So the Rms power is ~122W.
Re: Sct013-005 , unexpected results
Tungsten light bulbs also exhibit inrush - about 12-13 times is normal for a projector lamp. It's the temperature coefficient of resistance of tungsten that does it, with the temperature going from 290 °K to about 2700 °K or so. The easy way to check is measure the resistance cold with a multimeter, then calculate it from the power/voltage/current.
I've just measured a 40 W one. Cold it was 155 Ω, V2/ P = 1440 Ω so that's going to have an inrush current of about 9 times.
Re: Sct013-005 , unexpected results
Interesting information. Thx !
Re: Sct013-005 , unexpected results
Here's a pic of a 60W bulb lighting up. For maximum effect you need to time it so that you hit the cold filament right around Vpeak. It heats up quickly so things have calmed right down by the time of the next peak (at least for this bulb). After several attempts, 4.5A was about the best I could manage.
Re: Sct013-005 , unexpected results
That's something like 16 × the rms running current? And it's why such lamps always go 'ping' and die at switch-on.
Re: Sct013-005 , unexpected results
dBC, nice idea on having an alert and even shutdown related to the filter status.
Just added that to my TO DO list! ;)
Re: Sct013-005 , unexpected results
Yep, when the pump is being starved of water it's pattern is pretty recognisable (see image). Instead of being a nice steady ~1300W or so, it starts oscillating between that number and about 500W while it's sucking air. Then it re-primes and repeats forever (or until the impeller fails). My test is pretty simple: if the power has been in the 500-900W range twice in a two minute interval then raise an alarm. Occasionally I'll get false positives if I'm down there doing maintenance (switching things off/on manually), but I figure that's a good way of testing the tester every once in a while.
Smappee-like devices might get there one day, but in the meantime I find it's hard to beat per-breaker monitoring with bespoke rules written for expected behaviour and expected faults on each circuit.