SIGNIFICANTLY INACCURATE emonTxV3_4chan_continuous

I am collecting my data from 3 cts + 1 ac-ac adaptor connected to an emonTx with emonTxV3_4chan_continuous fw, it is connected to emoncms through Nanode with NanodeRF_multinode, my emoncms uid is mpower.

My readings are significantly inaccurate.

First: I have 3 CTs connected to Node:10, name 2, 3 & 4; nevertheless I am getting an input on name 5, even with ALL CTs disconnected, i still keep getting an input on name 5. Can you assist in troubleshooting this??

Second: From reading the code, i understand that name 1 field is the msgNumber value, is this correct, then what is the point of transmitting the msgNumber value??

Third: I am logging the input in Node: 10 name 2 and converting this feed to power, I am getting significantly wide readings compared to my mains meter reader, e.g at the moment, Node 10 name 2 is reading value of 42, while my mains meter is showing a consumption of 290 watts. What could be causing the wide discrepancy??

Fourth: My other two connected CTs may not be accurate or close to accurate as well. as comparing the inputs and load connected to them. Could you please advise on how i can verify the readings??

glyn.hudson's picture

Re: SIGNIFICANTLY INACCURATE emonTxV3_4chan_continuous

We have not properly tested or calibrated the 4chan_continuous code on the emonTx V3 as is stated in the comment at the beginning of the sketch. The main firmware we have released with the emonTx V3 is the discrete sampling  https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV3/RFM12B/emonTxV3_RFM12B_DiscreteSampling. Please contribute back if you do manage to calibrate the continuous sampling. I will try and make this more clear in the gitHub readme

glyn.hudson's picture

Re: SIGNIFICANTLY INACCURATE emonTxV3_4chan_continuous

Github readme documents have now been updated 

TrystanLea's picture

Re: SIGNIFICANTLY INACCURATE emonTxV3_4chan_continuous

Hello mpower, I have fixed and updated the calibration constants in the example, the calibration constants now use the theoretical calibration value determined from the component values. The updated example is up here:

https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxV3...

Lines 113 to 118 now read:

const float powerCal_CT1 = (276.9*(3.3/1023))*(90.9*(3.3/1023)); // <---- powerCal value
const float powerCal_CT2 = (276.9*(3.3/1023))*(90.9*(3.3/1023)); // <---- powerCal value
const float powerCal_CT3 = (276.9*(3.3/1023))*(90.9*(3.3/1023)); // <---- powerCal value
const float powerCal_CT4 = (276.9*(3.3/1023))*(16.6*(3.3/1023)); // <---- powerCal value (2000 / 120R burden resistor)

To add: the channels read a little high when no CT is connected but if the CT is plugged in and no power is flowing the measurement does go to zero.

Edit: Voltage calibration constant was also incorrect and has been updated to 276.9 which is the calibration constant as determined theoretically (230V x 13) / (9V x 1.2) = 276.9. Where 13 is the voltage divider reduction factor and 1.2 accounts for 20% increase in voltage adapter output voltage as its not being loaded (open circuit)

The measurements are now agreeing within 5-10W @ 3kW with my reference meter here.

mpower's picture

Re: SIGNIFICANTLY INACCURATE emonTxV3_4chan_continuous

Thanks guys for the updates;  I am getting ~10 - 12W @ <0.2kW when compared to the billing meter.

 

Anybody using the emonTx V2 should remember to set the pins correctly.

----------------------------------------------------------------------------------------------------

// analogue input pins (for emonTx V2):
const byte voltageSensor = 2;       // analogue
const byte currentSensor_CT1 = 3;   // analogue
const byte currentSensor_CT2 = 0;   // analogue
const byte currentSensor_CT3 = 1;   // analogue
const byte currentSensor_CT4 = 4;   // analogue

-----------------------------------------------------------------------------------------------------

 

Could you please confirm if the below convention also valid for the emonTx V2??

--------------------------------------------------------------------------------------------------------------------------------------------------------------

//emonTxV3 CT channel will read ADC 0 when nothing is connected due to switched jack plugs connecting ADC to 0V when no jack is inserted
  if (analogRead(1) > 0) CT1 = 1;               //check to see if CT is connected to CT1 input, if so enable that channel
  if (analogRead(2) > 0) CT2 = 1;               //check to see if CT is connected to CT2 input, if so enable that channel
  if (analogRead(3) > 0) CT3 = 1;               //check to see if CT is connected to CT3 input, if so enable that channel
  if (analogRead(4) > 0) CT4 = 1;               //check to see if CT is connected to CT4 input, if so enable that channel

---------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Finally i tried to UNSUCCESFULLY to add collecting of Vrms in emonTxV3_4chan_continuous by adding the following bits within the code. Do you have any hints on how i can get it to work??

____________________________________________________________________________________________

#include "EmonLib.h"                     // Include Emon Library                                                                                                                |
EnergyMonitor ct1;

/*
typedef struct { byte dumpState; int msgNumber; } Tx_struct;    //  data for RF comms
Tx_struct tx_data;
*/
typedef struct {
   int msgNumber;
   int Vrms;
   int power_CT1;
   int power_CT2;
   int power_CT3;
   int power_CT4; } Tx_struct;    // revised data for RF comms
Tx_struct tx_data;

void allGeneralProcessing()
{
  static int samplesDuringThisCycle;             // for normalising the power in each mains cycle
  static long sumP_CT1;                              // for per-cycle summation of 'real power'
  static long sumP_CT2;                              // for per-cycle summation of 'real power'
  static long sumP_CT3;                              // for per-cycle summation of 'real power'
  static long sumP_CT4;                              // for per-cycle summation of 'real power'
  static enum polarities polarityOfLastSampleV;  // for zero-crossing detection
  static long cumVdeltasThisCycle_long;    // for the LPF which determines DC offset (voltage)
  static long lastSampleVminusDC_long;     //    for the phaseCal algorithm
  static int Vrms;
  static int msgNumber = 0;

if ((cycleCount % 50) == 0)
        {        
          tx_data.msgNumber = msgNumber++; // increment
          tx_data.Vrms = ct1.Vrms*100;
          tx_data.power_CT1 = energyInBucket_long_CT1 * (powerCal_CT1/50);
          tx_data.power_CT2 = energyInBucket_long_CT2 * (powerCal_CT2/50);
          tx_data.power_CT3 = energyInBucket_long_CT3 * (powerCal_CT3/50);
          tx_data.power_CT4 = energyInBucket_long_CT4 * (powerCal_CT4/50);

          send_rf_data();        
        
          Serial.print(tx_data.power_CT1);
          energyInBucket_long_CT1 = 0;        
          Serial.print(", ");
          Serial.print(tx_data.power_CT2);
          energyInBucket_long_CT2 = 0;
          Serial.print(", ");
          Serial.print(tx_data.power_CT3);
          energyInBucket_long_CT3 = 0;
          Serial.print(", ");
          Serial.print(tx_data.power_CT4);
          energyInBucket_long_CT4 = 0;

          Serial.print(", ");
          Serial.println(tx_data.Vrms);
         
          Serial.print(", ");
          Serial.println(samplesDuringThisCycle);
  
          digitalWrite(LedPin, tx_data.msgNumber & 0x01);

_______________________________________________________________________________________|

 

Robert Wall's picture

Re: SIGNIFICANTLY INACCURATE emonTxV3_4chan_continuous

First, anyone with an emonTx V2 should stay with the emonTxV2 sketches - these are tried and tested on the V2, else as you point out the pin allocations are wrong. The convention for turning on various sections of code has changed over time so it's not safe to make general assumptions, you need to look at and understand the particular sketch.

Second, your Vrms problem:  In what way is it not working? Is there a sensible value in ct1.Vrms? You might like to look at  RFM12B - Part 2 - Sending Data Between Modules.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.