Archived Forum

Calypso_rae advocated this some time ago and his design for the Mk2 router uses a shared bias (so it's not a new idea). But he's found in practice that it makes no measurable difference.

Why do you presume it would be "extremely accurate if all resistors and capacitors had the same values"? The RC time constant is very long compared to the operating frequency (50 Hz) and the offset is removed in the software anyway. The only difference it makes is if the midpoint is not exactly in the middle, it reduces the headroom slightly - by 1% if you're using 1% resistors.

Thanks for the reply, that's true, bad presumption from my part. I thought about adding a regulator to the biasing circuit, will it  increase the error proportionally to the difference between the voltage in the Arduino and the voltage in the circuit?.

Sorry, but you haven't explained what you are thinking. Can you explain where the error that you are worried about arises? And which voltages are you talking about?

I get the following output from my 4 ct's,

2.35    2.42    2.37    2.46

2.37   2.39    2.41    2.32

2.44    2.31   2.33   2.38

As you see the values oscillate within a range not greater than 0.15 A

According to my boss there is something wrong with the circuit, I then changed part of the circuit and it turned out to be the same. Now he says that he wants the basing circuit to be shared and also regulated to operate on 5 V . My first thought on that was that the adc inside the arduino uses a reference voltage equal to vcc, that means that the readings taken in the arduino will be from 0 V - to vcc in the equivalent digital scale (0-1023),  if the voltage. If I in example get 4.5 as the voltage in the circuit then the mid point will be roughly 2.25 and the mid point for the arduino at lets say 5.2 V will be 2.6V  that means a possible error of 13 percent (if I am right)

The short answer regarding the reference voltage you mention is that variations are taken care of in the emonlib library functions and the absolute value in the calibration procedure you do when commissioning.

"If I in example get 4.5 as the voltage in the circuit then the mid point will be roughly 2.25 and the mid point for the arduino at lets say 5.2 V will be 2.6V  that means a possible error of 13 percent (if I am right)"
No, all it means is that the available dynamic range of the input is reduced. In your example zero input will read 433 counts, so your maximum peak-peak input amplitude before clipping is 886 counts rather than 1024. After the high pass filter in software, the signal is still centred about zero, just as it was before. There's no sensible reason to have a different supply for the processor and the bias, and as I think I've shown above, every reason to share the same supply.

There is the possibility of very small crosstalk between the inputs due to the sample and hold capacitor acting as a charge pump. This can largely be removed by changing the configuration of the inputs.

Without knowing what your circuit arrangement is and your component values are and what your construction method is, and indeed what those numbers your quote are, it's hard for me to diagnose your problem. However I think what you are reading might be digital noise picked up on the analogue input, either due (as pointed out elsewhere quite recently) to a lack of decoupling on the Arduino circuit boards, or poor layout and grounding in the analogue front end.

My construction methods are questionable, I don't have much access to electronic components so I had to make use of what I had in my shed, I used the circuit described in the building blocks section 2 10k resistors and 1 10 uF capacitor, I've got all four circuits connected to the same ground and vcc all soldered on a perfboard, the sensors are connected through 3.5 mm females plugs for great parts of the connections I had to use wires which are not hanging but soldered to the perfboard . Do note that the circuit is about 1.5 meters away from a 2  power inverters rated for 4 kW if it matters. What do you mean by changing the configuration of the pins?

I'm trying to understand what you've got but you're not giving me the information I need.

building blocks section 2
Sorry, I don't recognise that, Building Blocks sections aren't numbered. Give me the full title or the URL.

Which current transformer do you have (ratio?) and what value of burden resistor?

What do the numbers that you quoted mean? Are they power (if so what voltage do you have?), are they current? What are the units? Are they the output from a published sketch, if so which? (URL again). What calibration factors have you used?

Without all that, all I can tell you is that with the emonTx pcb (see "Modules" for photos), we routinely see an output of a few watts on a 240 V supply, which is due to digital noise transferred into the analogue to digital converter and rectified by the software. Anecdotally, we've tended to see more reports of higher values with the sort of construction that you are using. Remember that 1 count at the ADC represents a voltage change of roughly 5 mV, so you need to make sure there is no induced current or voltage reaching the analogue inputs.

You might also like to look at Atmels's website and get hold of the application notes that give some information about best practice.

I'm sorry for that Robert, I am using voltage output ct sensors, specifically the sct-013-030. I don't know the ratio nor the burden resistor, for I haven't torn the sensor apart.

The circuit is the one described in this link:

 http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor

The numbers I quoted stand for current, my construction doesn't make use of the voltage sensing. I'm using emonlib in order to calculate the current in Amperes, I had to make a few modifications to the library to make it work with an arduino mega 2560.

Regarding the induced current and voltages in the analogue inputs what is the appropriate tool or method to use? Please do note that my knowledge in electronics is for the moment somewhat limited.

I will have a look at atmel website.

Which sketch are you using?

What are your calibration factors?

What changes did you make to the library?

  delay(2); // Wait for Vref to settle
  ADCSRA |= _BV(ADSC); // Convert
  while (bit_is_set(ADCSRA,ADSC));
  result = ADCL;
  result |= ADCH<<8;
  result = 1126400L / result; // Back-calculate AVcc in mV
  return result;

I'm using the current-only sketch, I modified the library in the EnergyMonitor::readVcc() method, it looked like this:

long EnergyMonitor::readVcc() {
  long result;

  #if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328__) || defined (__AVR_ATmega328P__)
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1); 
  #elif defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  #elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
  ADMUX = _BV(MUX5) | _BV(MUX0);
  #elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
  ADMUX = _BV(MUX3) | _BV(MUX2);
  #endif

  delay(2);     // Wait for Vref to settle 
  ADCSRA |= _BV(ADSC);    // Convert
  while (bit_is_set(ADCSRA,ADSC));
  result = ADCL;
  result |= ADCH<<8;
  result = 1126400L / result;   //1100mV*1024 ADC steps http://openenergymonitor.org/emon/node/1186
  return result;
}

now it looks like this:

long EnergyMonitor::readVcc()
{
  long result;
  // Read 1.1V reference against AVcc 

  #if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328__) || defined (__AVR_ATmega328P__)
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1); 
  #elif defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  ADCSRB &= ~_BV(MUX5); // Without this the function always returns -1
  #elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
  ADMUX = _BV(MUX5) | _BV(MUX0);
  #elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
  ADMUX = _BV(MUX3) | _BV(MUX2);
  #endif
  delay(2); // Wait for Vref to settle
  ADCSRA |= _BV(ADSC); // Convert
  while (bit_is_set(ADCSRA,ADSC));
  result = ADCL;
  result |= ADCH<<8;
  result = 1126400L / result; // Back-calculate AVcc in mV
  return result;
}

The calibration factors are 30.0.

There is the possibility of very small crosstalk between the inputs due to the sample and hold capacitor acting as a charge pump. This can largely be removed by changing the configuration of the inputs.

Robert, can you explain this a bit more please?  Are you talking about software configuration of AVR inputs or are you talking about  hardware configuration, like reducing the source impedance?

The current-only sketch as published prints "estimated" power - the measured current multiplied by the presumed voltage of 240 V. If you have not changed that, then the numbers are actually quite good for the degree of noise and pick-up we usually see. If you have changed it and you are printing current ( Serial.print(ct1.Irms); etc) then you appear to have a huge input coming from somewhere. With an emonTx - where the input circuitry is on the same pcb - I expect to see about 40 VA or 30 - 50 mA of pick-up on any input (with a burden resistor present but no c.t. connected) and your calibration values.

Obvious question maybe: Is the "battery" voltage correct since you changed the library? - it should be close to 5000 for a 5 V supply.

I'm assuming those readings persist, you have waited 30 s or so for the digital filters to settle?

Are the 2.3 - 2.5 A numbers with a c.t. connected, or without? Can you disconnect the c.t. and put a short circuit in its place, what do you read then?

When I said "charge pump", to understand it you must draw a voltage input and a current input, and the multiplexer switch inside the ADC and the sample and hold capacitor also inside the ADC. When you do that, you can see that each time the multiplexer switches, it transfers the charge left behind on the S&H capacitor onto the 10 uF decoupling capacitor belonging to the input it has just switched to. The result is - in theory at least - you get a very small version of the voltage wave transferred to the current input. The reverse ought to happen too, but the current input voltage is usually a lot smaller than the voltage input voltage so it is swamped. The effect should be reduced if the input circuitry is rearranged so that one side of the sensor (voltage or current) is directly grounded, then the 10 uF is used like the input of an audio amplifier to couple the alternating voltage into the ADC input, which is biased to half supply voltage by the resistor pair. That's because the charge leaks to ground via the c.t. and the burden in parallel = 50 R approx, rather than through the two 470 K bias resistors in parallel, and is gone in well under a microsecond.

http://openenergymonitor.org/emon/node/1385#comment-7525  onwards.

Very detailed thanks.  I'd noticed similar crosstalk on my two analog tank inputs and cured it by introducing op-amps to lower the source impedance (similar to calypso_rae's solution).

I have updated emonLib with the fix for the ATmega2560. Please could you test that it works. 

https://github.com/openenergymonitor/EmonLib/blob/master/EmonLib.cpp

Thanks a lot for the fix. Keep up the good work! 

dBC,

I think you cured it not because you lowered the impedance, but because you shifted the midpoint just enough to move it away from the boundary between two ADC steps. As the simulated peak-peak amplitude is much less than 1 ADC step, you will expect to see the effect only if it causes transitions across the step boundary.

Thank you @Robert Wall,you've been of great help. I will do some testing and come back with the results. @glyn.hudson I will test the current version and let you know how it went

I think you cured it not because you lowered the impedance, but because you shifted the midpoint just enough to move it away from the boundary between two ADC steps. As the simulated peak-peak amplitude

Actually my AVR ADC only measures very slow moving DC inputs (rainwater tank levels).  If the two tank levels were different enough (which they can be) then one would impact the other via the exact crosstalk method you described in your pointer above.  By driving those two A/D inputs with an op-amp (to lower the source impedance) those AVR internal capacitors charge/discharge much faster, so the results stabilise much sooner.

I think I referenced the wrong Robin above.  It was the other Robin who put  op-amps on his A/D inputs like I have (in your detailed analysis thread referenced above).