Archived Forum

My preference would be to comment out (or even delete) all references to CT2 and CT3 and their associated variables and take their two respective powers out of PayloadTX as well - remembering of course to do the same at the other end (base or GLCD or both)

Setting CT2 = 0 only prevents the input being read and the rms current, power, VA and power factor from being calculated, it doesn't remove the variables and (as you've found) it still sends zero values. You can if you wish send these other values to the other end as well as power and voltage, you need something like:

typedef struct { int power, apparentpower, powerfactor, Irms, Vrms; } PayloadTX;

then inside loop( ) where you assigned power1 (look at EmonLib.cpp for the variable names):

emontx.power = ct1.realPower;
emontx.apparentpower = ct1.apparentPower;
emontx.powerfactor = ct1.powerFactor * 100;
emontx.Irms = ct1.Irms;

Or of course any combination of these of your choice! Then you need to follow this through in the emonBase, emonGLCD and emonCMS software.

(Note: I'm multiplying pf by 100 to keep it as an integer with 2 significant decimal places. You need to divide by 100 when you display or record it! - alternatively, you could define it as a float).

Sorry - I missed seeing your post earlier!

The 122 A problem. Those two numbers are consistent with a 240 V supply, so:

1. Where are you reading that? Not multiplying by 10 where you shouldn't be? ! ! !
2. Check your burden resistor is the correct value. It is the one right next to the c.t. input socket and right on the edge of the pcb. It should be 15 or 18 Ohms. (Brown-green-black-gold-brown or brown-grey-black-gold-brown).
3. Check you have the correct calibration constant for your current transformer. If you have the standard YHDC SCT-013-000 it should be 111.1  (line 41:   ct1.currentTX(1, 111.1);        
   (see http://openenergymonitor.org/emon/buildingblocks/ct-sensors-introduction and http://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor... for anything else).

If it isn't one of those, I need to think about it!

emonTX sorted, was a rookie mistake, took it to work with me to try and get a few mins to think about it logically amd then noticed after much metering and confirming the CT was ok that I'm in CT2 and the code reads from CT1. Changed it over in the code and bingo, able to calibrate it all again and working nicley.

Now got to sort why the NanodeRF wont last more than 5 mins as a base......

"Now got to sort why the NanodeRF wont last more than 5 mins as a base......"

There's much about that in the forums earlier in the year. I think the favourite is serial output being left turned on. Remove all Serial.  ....  statements (or wrap them inside a  #ifdef  / #endif pair and then comment out the corresponding #define)

IIRC, there was a problem with a duff batch of power supply regulators, but if you got your kit recently that should not be the problem.

Thanks for the reply

I tried commenting out the #define for the serial output but it didn't make any difference. Its seems to be running but not always getting the data to emonCMS, the red light comes on for a long while and then resets itself. Looking at my account on emonCMS its posting for a while then disappears for 10 minutes and then back again.

I had the serial output monitoring it and that is seeing results, although a bit sporadic, also keeps requesting time which is always 1 hour out. Could that be related?

I got the kit quite a while ago so maybe it is a duff 1702? I'll get it replaced in case as it does seem to be worse now than when I run it before.

If you know the date when you bought the kit, check with Glyn / Trystan - I think they'll know which kits and when the duff batch was sent out.

Time is UTC, is it not?