Archived Forum

The method that most people adopt, bearing in mind the difficulty of accurately measuring current and voltage to a similar accuracy to the calibration of your supplier's meter (there's a Building Blocks page about multimeters that you might like to read if you haven't seen it) is to apply small corrections over time so that the energy readings agree with the supplier's meter and generation meter. Unless your multimeter is particularly good, you're unlikely to get much closer than you already are by measuring and working out the calibration constants for voltage and current separately. For the phase shift correction, Robin's tool here is probably a good way to go. I understand that with careful adjustments over time, you can get to better than 1% agreement between emonTx and your supplier's meter.

Thanks for the prompt response. So you're telling me that the error that I see is reasonable provided all the uncertainties in the system, the difficulties in precise measurements and the way the calibration is done through two separate constants. I then suppose that moving to the new sketch won't provide me with more accuracy as the calibration is supposed to be done the same way, i.e. with the same type of uncertainty, isn't it?

Maybe the best approach to achieve my goal is to apply corrections over time, as suggested, rather than chasing the best combination of constant values. This means that using theoretical values instead of values found during calibration is not going to make a large difference if then I will correct the results: have I got your point?

I have another question about the emonTx_continuous_watthours sketch to be applied to the emonTX V2.

At line 65 we found the definitions for the analog inputs, that actually fits the emonTX V2 setup:

// analogue input pins
const byte voltageSensor = 2;     
const byte currentSensor_CT1 = 3;
const byte currentSensor_CT2 = 0;
const byte currentSensor_CT3 = 1;

At line 290, where the ISR routine starts, I see that the samples are read referring to the wrong inputs. For example, sample_V (that should refer to the voltage sensor) is read from the input 0 where is supposed to be connected the current sensor 2. Is it correct? It is going to mix up voltage and current, unless I miss something... The same mix is for the rest of the inputs.

ISR(ADC_vect) 
{                                        
  static unsigned char sample_index = 0;
 
  switch(sample_index)
  {
    case 0:
      sample_V = ADC;
      ADMUX = 0x40 + currentSensor_CT2; // set up the next-but-one conversion
      sample_index++; // advance the control flag            
      dataReady = true;
      break;
    case 1:
      sample_CT1 = ADC;
      ADMUX = 0x40 + currentSensor_CT3; // for the next-but-one conversion
      sample_index++; // advance the control flag               
      break;
    case 2:
      sample_CT2 = ADC;
      ADMUX = 0x40 + voltageSensor; // for the next-but-one conversio
      sample_index++; // advance the control flag               
      break;
    case 3:
      sample_CT3 = ADC;
      ADMUX = 0x40 + currentSensor_CT1; // for the next-but-one conversion
      sample_index = 0; // advance the control flag                
      break;
    default:
      sample_index = 0;                 // to prevent lockup (should never get here)     
  } 
}

Thanks again for your help.

Have a good day,

Alberto

The clue is in the comment:   

// for the next-but-one conversion

When you run the ADC in continuous mode, by the time this ISR fires, it's already sampling the next input (as selected by the last write to ADMUX).  The write you see here is telling it which one to start sampling, after the current sampling interval completes (when the next ISR fires).

So there are 3 conversions in the pipeline if you like:

. the one it's just completed (result is read from the ADC register above)

. the one it's currently working on (as selected by an earlier write to ADMUX)

. the one you want it to work on next when it's finished this one (specified by the above writes to ADMUX)

Strictly speaking, the code is really setting it up for the next conversion, but the comment probably refers to that as "next but one" because it'll be available at the next but one interrupt.  The next interrupt will provide you with the current conversion, the next one after that will provide you with the conversion you've just selected via ADMUX.

Regarding your calibration accuracy, the theoretical values take no account of real components. Have you read the notes in Building Blocks about the sources of error? I think you're not clear in your mind about two different sources of possible error. The easy one to understand is due to the inability to make the components to perfectly accurate values. Calibration takes care of that.

What you might also be struggling with (it's not very clear from your posts) is also inaccuracy that arises from how the power is sampled to get the readings. The "continuous" sketch does what it says, it monitors continuously, adds up the energy that goes past during the sample period, and reports that (or divides it by the time elapsed and calls it average power). The "discrete sample" sketch measures power over a short period (10 cycles by default) and assumes that the power was constant at that value since the last sample 10 s ago.  Therefore, if you have an appliance like an induction hob, that switches on and off rapidly, the "discrete sample" sketch is likely to report it at full power for 10 s even though it only happened to be at full power for 1 s before the sample was taken and for 2 s after - which would give you a 333% (approx) error for those 10 seconds.

Thanks very much for your responses and suggestions. I have worked on the system during the weekend and I've ended up into frustration: I am lost and I can't figure out what's wrong. I'm close to give up.

I decided yesterday to move to the continuous sketch by calypso_rae. I have not fully clear in my mind all the implications of the measurement system, but it is definitely using an approach closer to what I would have done.

So I wanted to start re-calibrating my emonTX V2.2: I took a 60W bulb lamp and prepared a long wire. Then I made 20 loops of the wire into the CT1, 20 loops into CT2 and 20 loops into CT3. I loaded the PhasecalChecker sketch from calypso_rae to get the correct values: I didn't manage to find a single value in the range of 0.00-2.00 to give me a Power Factor better than 0.91 with none of the CTs. I get always a high value for the apparent power, almost constant. So I left this check and started working on the continuous sketch.

First of all I measured the open-circuit output from my FP AD 3515 AC-AC adapter: 12.56 V (on average) rather than the theoretical 9 V+20%. Another thing that I don't understand.

I then tried to adjust the powerCal factors in order to get reasonable values on CT1, CT2 and CT3. First of all three reasonable readings provided the uncertainty on the load and then three similar readings. After having completed the calibration of the values on the 60W bulb (x20 loops = 1200W), I made corrections and calibration using a toaster (nominal 650W checked with 1 wire, 6 loops-3.9kW and  9 loops-5.85kW).

Then I moved the CT sensors on the main wire coming from the solar PV inverter realizing that the measured power was slightly less than the inverter was showing on its display, approx -3%. I didn't struggle on it as I've always supposed that the inverter over-estimates the production.

I moved the CT's on their final positions (CT1 on house loads and CT2 on PV supply, CT3 disconnected) and left it monitoring for some hours.

Provided that my main scope is to have a system that can report values comparable with the electricity company's meters, I decided today to implement a pulse counter to interface the PV dedicated meter, to be used as reference. In Italy the electric company installs a separate meter to measure the PV production only, in order to calculate the incentives to be paid on the production and the excess put in the grid. If the emonTX measures the same values as read by the flashing led of the meter, then my system is calibrated and it has the accuracy that I am looking for.

Here my frustration has started: I see that the emonTX reads an instant power that is approx. 3% less than the one measured by the meter. But the accumulated energy is much more than the real! To give you some numbers: I read the meter yesterday night (no sun): 12179 kWh. At this point in time it is 12196 kWh, i.e. 17 kWh of energy come from the sun. The emonTx (it was reset when I read the energy on yesterday night) reports 20.4 kWh. It is a 20% of error! Meanwhile, it reads an instant power of 2859 Wh while the meter gives 2951 Wh.

I am lost: how can I apply a correction factor that should be for increasing the reading if the overall total is already too big? I've started this revision because I wasn't happy of the 7% error I had and things have worsened dramatically. I'm really disappointed of myself and I am thinking to leave things as they are and give up.

Thanks,

Alberto

Robin (calypso_rae) has been on holiday, he may well respond shortly about your phase calibration problem. I'm not sufficiently familiar with his test sketches to comment.

"First of all I measured the open-circuit output from my FP AD 3515 AC-AC adapter: 12.56 V (on average) rather than the theoretical 9 V+20%. Another thing that I don't understand."
The "20%" is the regulation of the adapter. The actual value depends entirely on how the designer went about specifying the transformer. The 9 V output is on full load, when on no-load, the voltage will rise, and in your case - significantly. 20% is a typical value for the size of transformer we normally use, the regulation of yours is 39.55%.

That might be a problem. The incoming ac voltage (12.56 V rms) is divided in the ratio 10/110 inside the emonTx. That gives you 1.142 V rms. Assuming a perfect sine wave, that wave has a peak to peak value of 1.142 × 2 × √2, and that is 3.23 V. That is within 70 mV of the nominal voltage of the 3.3 V dc supply that the Atmel processor runs on, and that's too close - you have only 2% for all the resistor tolerances and the regulator tolerance, and that's assuming your mains voltage was at maximum when you measured it! It's likely that the voltage wave is clipping on one or both peaks. I suggest you solder a higher value resistor in parallel with R14 (say 100 kΩ) to reduce the voltage by a few percent. If you do that, you will need to recalibrate powerCal.

The other thing you need to check is, are you counting each pulse once and only once?  Is it possible that you are counting a flashing light from somewhere else? I think the voltage clipping is more likely to be the source of the error, because your power measurements will be non-linear according to the mains voltage. When the mains is high, you will measure low because the voltage wave is too low (clipping) at the peaks; and when the mains is low, you will measure correctly but you might have calibrated it when the mains was high and clipping, so it is still wrong!

Dear Robert,

Thank you for the explanation. I will try with the 100 kΩ resistor in parallel with R14 and perform a new calibration.

"The other thing you need to check is, are you counting each pulse once and only once?  Is it possible that you are counting a flashing light from somewhere else?"

I am quite sure that I am counting each pulse only once: I've used a sketch described at http://openenergymonitor.org/emon/node/123 and visually it was easy to follow either the blink and the serial output. When I was testing the production was between 1500 kWh and 3000 kWh, so the pulses frequency wasn't that high. I was in a completely dark room also. Moreover, I've been there waiting for the meter to turn 1 kWh and it happened at the same time with the sketch, so I am confident I didn't count pulses more than once.

Apologies for abusing of your patience, just to be sure I have got the point... assuming that the problem is in the voltage clipping, and assuming that my previous calibration wasn't that wrong (the first time I made it using a resistive load of about 600 W and no loops in the wire), it is possible that I was counting less energy than real because of the voltage clipping. Now that I moved to the continuous sketch and made a calibration with higher loads I am using higher than necessary values for powerCal (to read reasonable values according to the loads) and this affects the measure when the mains is low also. On the other hand, it looks like the measure of low mains is reasonably correct: with the latest calibration the CT2 (PV) measures the same value got reading the pulses (the difference is <0.5%). Is this the point? If so, I still don't understand why the measured power is less or equal than the "real" (coming from pulses) but the energy is much higher than the one measured by the meter. I would have expected less energy also! I moved from an error of 7% (under) to 20% (over).

One more thing: I have bought the AC-AC adapter from the OEM shop as it was (at that time) the only one with the Euro plug. I did assume that it was tested and approved for the project, as explained in the website. So my question is: may I have encountered a "faulty" device? Worth it to replace it or proceed with the R14 workaround?

Thank you,

Alberto

When I wrote that the regulation of your adapter was 39%, I'd forgotten that you had not specified the mains voltage when you measured the output. The link to the supplier now appears to show a different item, the one now listed is 9 V out for 230 V in, with load regulation quoted as ±30.8%. Until I know the output at full load at the nominal mains input voltage, it's hard to say whether yours is in fact faulty. If the output waveform looks distorted, it might be worth changing it. Otherwise, I recommend you add the resistor - it's a lot cheaper. You could try Robin's Min/max sketch, or RawSamplesTool_4ss_2, to check the limit values you're actually seeing. But that is only definite proof of the problem when you do it at maximum mains voltage, otherwise you need to scale the values according to how far below the maximum voltage your mains is when you do the test.

Where is the energy calculation coming from, that you say is 20% high? If I interpret you correctly, you are measuring real power from your emonTx and calculating power from the pulse rate on your PV export meter, and they agree within 0.5%. Yet when you put that power into somewhere and perform the integration over time (emonCMS?), the integrated energy value shown there is 20% (possibly - if your meter does not display decimal fractions, it could be 17.999 kWh, 13.3%) higher than your PV export meter has recorded.

Let's make sure the voltage wave is correct first. As the system will be non-linear if clipping is present, it's hard to say exactly what is going on.

Yes, I'll manage to add the resistor first, as soon as possible. Actually I didn't measure the mains voltage when I measured the output of the adapter on no load.

To explain the origin of the 20%: I measure the real power from the emonTx using the Robin's emonTx_continuous_watthours sketch. This sketch provides as output on the serial monitor either the instant real power and the energy (counted from the power up) for every CT channel. I reset the emonTx at midnight and left it running over night and today also. Today at noon I have checked the measure from the emonTx (PV energy) and it was 12,2 kWh. I read the same value on the PV meter and it was 10 kWh (no decimals available but it took more than 25 minutes to go to 11 with sun power around 3 kWh). The inverter was saying 10.1 kWh at the same time.

After this a took another Arduino board and I implemented the pulse counter on it. I wanted to use it as reference for the energy. I then realized that the real power coming from the emonTx was always lower than the power computed by the pulse counter: the difference was approx. 3%. Despite this, the energy calculated by the emonTx was much higher.

Both the emonTx and the pulse counter provide the energy as output at the resolution of 1 Wh. With the pulse counter the assumption is that that's exact energy counted by the mains company, so it is my reference. It was easy to see how quick the two energy values were diverging: within 100 seconds with a sun power almost constant, the emonTx was integrating 28 Wh more than the pulse counter (on a total of 100 Wh). Values to low to be used for an analysis, but they give the idea of a trend in the gap that was clearly diverging whilst the power reported by the emonTx was lower than the pulse counter's one.

I then decided to play with powerCal in order to make the two powers be the same as much as possible and I found out the constant values that make the difference to be within 0.5%. At this point the divergence of the energies was huge, the sun was going down, then I asked for help...

I'll load that sketch into an emonTx V2 and run some tests for you, but it will not be for a day or two. Your mains supply is 50 Hz?

230 Vac - 50 Hz. Thank you!

There is a problem in the maths.

I've run the current Github sketch on my CT test rig, with a more-or-less constant "power" of 12.5 kW for exactly 10 mins as measured by the emonTx, and dropped the numbers sent in the RF packet into a spreadsheet.

There are 61 sets of values. The accumulated Wh went from 13510 to 16122, an increase of 2612. Multiplying by 6 (to take it up to one hour) = 15672. The average power over the period was 12537 W. I think that the accumulated Wh is exactly 25% over. (The ratio is 1.2500598229 and that's close enough!)

There are 375 messages (i.e. the accumulators have been added to that many times), but if that is supposed to happen every 2 s, there should have been 10 x 60 / 2 = 300 messages only, which exactly the same proportion that is the excess in the accumulators.

The problem is in the "switch(sequenceCount)" statements at line 449. The sequenceCount counter is being reset after 80, not 100 counts as it should be (there are 100 cycles in 2 s). So it's necessary to change "case 80:" to "case 100:" at line 503, and in the default case, similarly make it "if (sequenceCount > 100)".

With those changes done, the discrepancy is -0.063%.

NOTE: This sketch is specifically for a 50 Hz system.

Thanks Robert. 

Although my name appears at the top, that version of the "continuous" code was not done by me :)

Thanks very much for spotting this Robert, I've updated the code on github.

Thanks, Trystan. Actually, Robin had told me that he'd spotted that the code had been changed in this area a little while ago, but at the time I hadn't looked closely and didn't appreciate that the error affected the calibration. All I did was verify the problem, home in the exact details, then verify the solution!

Robert, thanks a lot for your feedback. Regret the delay, I've been around for business so I could only add the change to the code on Tuesday night. Yesterday evening the emonTx was reporting 10.013 kWh of solar production; the company's meter and the inverter reported 10 kWh both.

It has been quite a cloudy day in here yesterday: I hope today will be better so I can verify it on higher powers too. It looks like the main source of the error was there. As my references (the inverter and the meter) do not display the decimal fractions, this is still a potential error of 1 kWh on 10 (worst case). During the next weekend I'll be able to better check it, but I am pretty sure that I will find the emonTx output extremely close to the meter's readings now.