Archived Forum

Have you calibrated your emonTx? Depending on the tolerance of the divider and burden resistors, the ac adapter, the c.t itself and the processor's internal reference voltage, at worst case those might indeed add up to close to your 15%. That is the first thing to do.

I don't think noise will decrease the reading - if anything it should increase it. Lost transmissions might affect the totalizer in the emonGLCD, you could prove this by adding a few lines in the emonTx and checking with the serial monitor.

[BTW, the unit of energy is kWh - watts times time to give the accumulated total. It's not kW per hour.] 

Thanks for the reply.

I can't find any instructions anywhere on how to calibrate emonTX. There are references to thesehttp://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor-installation-and-calibration-theory instructions, but it doesn't tell me HOW to do it.

Have I got to measure the mains AC and the PSU output AC simultaneously, and where do the numbers in the formula

voltage constant = 230 * 11 / (9+20%) = 234.26

come from ? I guess the 11 is the R13/R14 divder ratio, but 20% of what ? Can't be the 9 surely, why not just write 10.8.

I find these instructions very confusing.

Mike,

I think it is not really necessary  to understand the formula (which is a bit weird, using a percentage sign without clear reference inside the formula !?!).

You get a reading from your measurement either on the serial output of the emonTx or displayed on the emonGLCD or on one of the inputs of the emoncms. Then you measure the momentary value of your AC mains voltage with a true RMS multimeter. If these two values do not fit, change the voltage constant accordingly (use the ratio of measured to displayed voltage as correction factor).

Jörg.

PS: you do not say which sketch you are using, but the voltage constant is mostly specified in the function call like 

ct1.voltageTX(234.26, 1.7);

just change the 234.26 to the correct value.

OK. Thanks for the reply.

Re-reading the stuff all again, I think the formulea is

voltage constant = 230 * 11 / (9+20%) = 234.26

where 230 is the measured mains voltage, and 9+20% is the measured adaptor output voltage - a nominal 9v under full load + the "transformer regulation".

So I get 245.2 * 11 / 11.52 = 234.1319

The sketch emonTX_CT123_voltage used to have a value of 228.268 for CT1 and 234.26 for CT2. Not quite sure why they were different.

For the current side of things I'm using the standard SCT013 with 18R resistors. Tried measuring the 18R resistors & my meter just says 18 so they are either spot on or the variation is so small it's not measurable.

I'll reprogram emonTX with this and see how this compares with my generation meter over the next few days.

I've a similar problem with an SMA inverter, it under measures the kWh readings - over  a month about 2% out compared to an Elster AC100 meter.

I believe the accuracy required of the tariff meter is 1%, which might mean the two are at opposite ends of a 1% tolerance band.

In our house, we have the Elster AC100 which, like yours, acts as the reference for generation and billing. I also have an EnviR system which records visible generation meter pulses from the Elster and stores them on a display. This correlates very closely with the numerical output from the Elster and has the added advantage of giving the average power reading every six seconds or so. In addition to this I have one EmonTX unit which constantly reads the iRDA output of the Elster (and sends it to EMONCMS via the EMon Base unit and a second EMonTX which reads the voltage and power on both the generation circuit and the consumption circuit.

Over a twenty day period, as an example, I monitored the total energy generated using the Elster and compared it to the total Energy generated by the EmonTX and as read using EMONCMS. Bearing in mind that the Elster method is a direct read of the meter and the EMON TX method is a constant analog sampling approach with maths, the two would never be the same.

The EMON TX was under reading by 0.48% over 249 KWh of generation. Over this period roughly half the days gave a decent level  of PV and half were iffy to say the least. In my book, a fairly reasonable profile. 

Now, some may say that these results are flawed or less good than is possible. To me, they are pretty decent and show what is possible with a pretty inexpensive rig.

To get to this point I was very careful to site the voltage monitor close to the consumer unit which, in turn, is close to the generation meter and to accurately calibrate measured RMS supply voltage with a decent voltmeter. It's all about setting the calibration constants mentioned previously so as to align one with the other. FWIW, I constantly display the RMS supply voltage on an EMON GLCD display and periodically check it with a meter. I can see the voltage fluctuating as the household load changes, all in line with series resistance in the cabling.

From there I have tweaked the current ratios so as to correlate the average power during the sampling window with the power readings from the EnivR - it lining up very closely with the Elster over many months of measurement. Getting the current ratio values right takes a huge amount of tweaking over a long period. Even changing the current ratio by 0.01 can have a significant affect upon the power reading so you need to be patient.

I've tended to err toward getting a good current ratio at high power reading as this is most significant overall. That said, getting the current ratio right there tends to look after itself at lower power reasonably well as the EMON is reasonably linear (for me at least) unless I am trying to measure a really low power value. 

Overall, the EMON TX approach is really good. It's a lot more accurate than my other Wattson system (typical current clamp only , also known as a chocolate fire guard) and, with the added inclusion of the MK two energy dump, tank temperature monitoring on four nodes and visual alarms on both the web and on the EMON Base really cannot be beaten for the money in my humble opinion.

Ian, if you are up for it sometime, I'd be interested to know how well my ICAL calibration tool compares with your long-term determination of the current ratio (this sketch will calculate the current ratio from the visible meter pulses).

Did you spend much time looking at phase correction? Since you have very good results I'm assuming you must either have it very close or it is not that significant.

-martin

Hi Martin,

to be honest, I hadn't seen your sketch (having been away on business for much of very week recently). If I get the chance I will have a play with it.

In the early days I spent a huge amount of time playing with phase correction and goodness knows what else. I built loads of spreadsheets with varying phase calibrations and tuned things for various types of loads (not just resistive, although resistive tends to dominate when the power is high). As I recall, and it was back in January, the phase calibration didn't make a huge difference. The key thing was to get the voltage ratio correct first. This is a pretty easy thing to do as its simply correlating the emonTX reading with a decent voltmeter on the same monitor. This seems intuitive and visual. Current is less so. Like I said, that monitor needs to be pretty close to the generation meter so as to be accurate (at least with our house wiring). It's also important to put the monitor directly onto a main socket or to know what the performance loss of the trailing socket that you are using is. In my garage, which isn't blessed with masses of mains sockets but does have a huge range of power tools, several machines sharing the same trailing socket as the voltage monitor could introduce significant transient errors, for example.

I then started playing with the light bulbs and coils of wire which are popular on here. That gave me a feel for what the current drain was but it was far from accurate. So I bought a decent plug in energy monitor (the most accurate domestic one that I could find at a reasonable price) and cross correlated the power that this was reading with what the emonTX thought was there. I did the same for the measured supply voltage too. I also played with various load power factors (easy when you have a variety of electrical machines!). At this time I did phase correct sweeps and studied the results in excel. If I am honest, for the most part I found that the power measurement changes were gradual with varying phase cal. Within reason, the value chosen wasn't that important.

So, having set V and I cal values I started monitoring measurements through EMON CMS over a longer period. Typically, I ran for a day or more (as EMON CMS only gave me one decimal place) and I tweaked ICAL even more. I probably spent a good month overall tweaking until I settled on a figure. This section of the calibration made by far the biggest difference. In all honesty, I could almost rip up what I did with the light bulbs and with the electrical machines. The long term average approach was the best way. Having the ability to read watt hour values using the iRDA port on the Elster helps a lot and having the patience to wait over several days and recording from EMON CMS also helps. I revisited it several times since and tweaked ICAL again fractionally. Half a percent low is fine for me. I want to under read as this stuff is also used for the PV dump and I dont want to be paying for using the immersion heater!  

I feel lucky in that I have some decent enough references against which to calibrate. In some regards, getting VCAL and then tweaking ICAL so that it correlates with a medium term reference may be considered cheating by some. It gives correlated numbers  though and that's good enough for me at the moment.

Sounds like you've spent even more time on this than me Ian - and I thought I was obsessive! :)

Just be glad you've only got one phase to worry about. Imagine my situation with 3 VCALS and 3 ICALs to set and only one meter reading to compare it with. VCAL is ok, it just takes 3 times as long, but you can get in a right mess with ICAL. In the end I automated the process with a sketch that applies the dump loads to each phase in turn and measures the total power via the meter LED at the same time. This gives me 3 simultaneous equations with 3 variables which I can then solve with a matrix - all on the emonTx.

@ nothing clever 

I think you may find that your Elster A100C may not be as accurate as you may think especially in low light conditions on a 2kW system.

I find my Elster A100C doesnt measure small flows at all well. For example at dawn my energy import (Pulse Metered) drops off by upto 80W upto a couple of hours before my elster A100C says there is any generation. My consumption is static (other than my fridge freezers) yet my import drops this energy must be coming from my Solar PV but isn't being Metered. 

I ended writing my own routine for reading the Elster A100C irDA pulses which uses 600Bytes less ram than the previous one I used See Bellow. It may be of some use to those of you who wish to read the  A100C. I also have a version that will fetch the Serial No and Status bits If needed.

[code]

/*

Elster A100c Meter Reader Software
Reads a 2400 baud stream Stream Starts after MinimumInterBlockGap (uS)
(c) No one Please feel free to do with as you please.

*/
#define PulseGap 390  // Approximate Pulse Gap its actually 416uS But 390 allows a little margin for error
#define ReadByteLength 54 // The Number of Bytes to read from the stream we only need to read upto the end of the
#define MeterReadingDataStart 49 // The Starting Position of the BCD Meter Data
#define MeterReadingDataEnds 53 // The Ending Position of the BCD Meter Data
#define MinimumInterBlockGap 100000 // The Gap Between Frames In (uS)

volatile unsigned long LastPulse; // The micros() of the last Pulse
volatile unsigned long ThisPulseMicrosTemp; // The micros() of the this Pulse
volatile unsigned long MicrosSinceLastPulse; // Gap in uS Between This and the Last Pulse
volatile unsigned long NEWreading_A100C_Reading_1; // Varible To Convert the BCD Reading into
volatile byte BuffPtr; // Current Character Position in Stream
volatile byte ReadByte; // Current Character
volatile byte BitPos; // The bit position of the current Pulse
volatile bool FirstRead; // Flag showing this as the First read I ignore the first meter reading as it seems to be corrupt 1 in 10 times
//Following reads all seem fine.

void HandlePulse()
{
// Recieved an IR Pulse. Let the Games Commence
// Grab micros soon as the pulse arrives to give the most accurate Inter pulse Gap
ThisPulseMicrosTemp=micros();
MicrosSinceLastPulse=(ThisPulseMicrosTemp-LastPulse);
if (MicrosSinceLastPulse>MinimumInterBlockGap) {
  // Its a Big Gap ... The Frame has just begun
  BuffPtr=0;BitPos=0;ReadByte=255;NEWreading_A100C_Reading_1=0;
}
else
{
  // Process Each bit if we haven't Passed the end of where we want to read to.
  if (BuffPtr<ReadByteLength)
  {
   // Calculate the number of bits forward the next "0" pulse is
   BitPos+=(MicrosSinceLastPulse/PulseGap);
   if (BitPos > 8){

    // If the next "0" pulse is after the end of the byte
    // IE the next start BIT then the current Byte next valid character in the stream

     if (!(BuffPtr<MeterReadingDataStart) && !(BuffPtr>MeterReadingDataEnds))
     {
      // This character is part of the meter reading
      // Convert the BCD to Unsigned Long
      NEWreading_A100C_Reading_1=(NEWreading_A100C_Reading_1*100);
      NEWreading_A100C_Reading_1+=(ReadByte /16)*10+(ReadByte % 16);
      if ((BuffPtr==MeterReadingDataEnds)) // Its the Last Character Call the Reading Complete with the results
       if(FirstRead) FirstRead=false;  // If its not the first reading then ignore it.
        else ReadingComplete(NEWreading_A100C_Reading_1);    
     }
     BuffPtr++;ReadByte=255;BitPos=0;
   }
   else
   {
    // Unset this bit as it has a pulse in it and Pulses are 0's
    switch (BitPos){
     case 1:
      ReadByte -=1;break;
     case 2:
      ReadByte -=2;break;
     case 3:
      ReadByte -=4;break;
     case 4:
      ReadByte-=8;break;
     case 5:
      ReadByte-=16;break;
     case 6:
      ReadByte-=32;break;
     case 7:
      ReadByte-=64;break;
     case 8:
      ReadByte-=128;break;
    }
   }
  }
}
// Finally Don't Forget to set the last pulse time to this pulse time so we can calculate the next gap.
LastPulse=ThisPulseMicrosTemp;
}

void StartA100cMeterReader(byte IRQ){
// This Starts the meter Reader
FirstRead = true;
LastPulse=micros();
attachInterrupt(IRQ,HandlePulse,RISING);
}

void ReadingComplete(unsigned long Reading)
{
// This is called everytime there is a succesfull meter reading usually around once per second
// PS Calling Serial.print() in here is probably not a good thing as it is called from an ISR.

Serial.println(Reading);
}

void setup()
{

  /* add setup code here */

Serial.begin(57600);
delay(1000);
Serial.println("starting");
StartA100cMeterReader(0);

}

void loop()
{

  /* add main program code here */

}

[/code]