Archived Forum

Hello Juan,

Taking the CT first. Do you have a multimeter? If so, you can check which connections are used. Only two are used with our standard CT, tip and sleeve. There is no connection to the ring.

"the 3.5mm jack that I bought has only one output for the ring and the CT Sensor has 2 rings"

The female connector you have is, in audio terms, mono? If you have no connection to the ring on the plug (male) connector, the socket (female) connector you have should be OK.

For the voltage monitor, use the full 9 V if you have the voltage divider components specified.

The female connector is stereo, that is ok, I have just connect the CT Sensor (tip and sleeve [I used a multimeter]) but I don't know if I'm doing right because I get some dummy reads even without conect the CT to the female jack, this is a sample:

65.26 0.28

64.84 0.28

62.82 0.27

64.12 0.28

​63.54 0.28

...

91.09 0.40

​105.20 0.46

As you can see, sometimes I got values between 60.00 - 68.00 but also I got greater values, this is without connect the CT, but that doesn't matter because when I connect the CT I got the same values :(

I'm using the sketch of that page: http://openenergymonitor.org/emon/buildingblocks/arduino-sketch-current-only but I thinks I'm doing wrong because the sketch is for the european specifications and I'm from Mexico. Here the specification is 100 - 127 volts, 60 hertz electrical system.

In case of the transformer, when you use an AC-AC power supply, I think you have 2 outputs, live and gnd, right?

In the transformer, Do I have to connect both live terminals? Consider one as live and the other one as GND?

The sketch you are using shows only current. Many people report seeing low readings when there is no current flowing, and we are investigating to try to find the cause. I think it might be digital noise from the Arduino itself interacting with the analogue to digital converter. The error will become much smaller as the current gets larger ( > 1% of maximum current). In any case, unless you have changed the sketch ( the line

Serial.print(Irms*230.0);

must be changed to

Serial.print(Irms*115);

or whatever your normal supply voltage is)  you are reading twice as much power as there really is.  60 Hz compared to 50 Hz should make no difference - except that it will take fewer reading for each cycle of mains.

Now voltage:

The secondary winding of your transformer is "centre-tapped". That means it has a connection at the centre of the winding. It gives you 9 V measured from end to end, and 4.5 V across each half. You will not use the connection to the centre, and it does not matter (for this sketch) which end you call ground and which you call "9 V".

But to measure and use the voltage, you need to use a different sketch. Try http://openenergymonitor.org/emon/buildingblocks/arduino-sketch-voltage-...

You will need to change the calibration in this line:

emon1.voltage(2, 234.26, 1.7);  // Voltage: input pin, calibration, phase_shift

to suit your mains voltage. The theory is here: http://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor... and I think you need to change 234.26 to about 117 (it might be less than 117, and it could be as big as 140). If you do not know the exact details of your transformer, you must measure the mains voltage (TAKE CARE!) and adjust the calibration constant in the software to give the correct answer.

If now this sketch gives a negative number for power, you must either reverse the connections to your voltage transformer, or reverse the CT on the cable.

Hi Juan,

Power requirements for the Uno are nicely described at http://arduino.cc/en/Main/ArduinoBoardUno.  The easiest way to power  Arduino is via a USB cable.  For standalone mode, you need to provide a 9V DC supply or similar (not AC).  I've found an old  9V 200mA centre-positive AC-DC adapter which is working fine.

For measuring mains voltage, you need to provide a stepped-down version of the mains voltage to the Arduino's input.  Your 9V transformer would do nicely, but do make sure that the voltage is sufficiently reduced.  I'm also using a 9V AC supply which is further reduced by a factor of ten.

The secondary coil of your transformer must be completely isolated from ground.  By tying it to the 2.5V reference at just one point, an AC signal centred at 2.5V is available at the input pin.

Good luck

Hello again!

After a lot of attempts, finally I'm getting good readings from the CT Sensor, the problem was my wiring, I'm only need to solder the wires to the female 3.5 jack to fix it.

Now, the specification of the transformer are:

INPUT : 127V, 60Hz
OUTPUT: 9V, 300mA

But I'm measuring an output of 10V and 320mA, with this data and according the formula of AC Theory I ​calculate the voltage constant in ​110​.

Now, reading the calibration theory, I notice that this formula   

counts = (input pin voltage / 3.3) x 1024

is considering that the arduino output is 3.3V, and I'm using the 5V output, Can this affect the measuring?

"Now, reading the calibration theory, I notice that this formula   counts = (input pin voltage / 3.3) x 1024 is considering that the arduino output is 3.3V, and I'm using the 5V output, Can this affect the measuring?"

No, if you continue reading: "However, the processor is able to measure its own reference voltage, this and the full scale count are already included in the program. This removes these steps and simplifies the calculation".

The 320 mA you measure is not relevant, because when the transformer is used as a voltage monitor, it delivers almost no current. In that case, it is quite normal for the output voltage to be higher than the label states (+25% is not unusual for a small transformer). The numbers you need to calculate the voltage constant are the supply voltage and the transformer output voltage (measured at the same time, because the supply voltage can and does vary). If you measured 10.0 V when the supply was 117 V, then I think your voltage constant is 128.7. Of course, this might still be wrong because the resistors might not be exactly the correct value. You might need to measure the supply and adjust the voltage constant so that your display reads the correct value.

Hi Juan, It may not be worth going to a lot of effort to calculate VCAL and ICAL.  The best calibration values for your circuit are those that make your readings agree most closely with measurements taken with accurate test equipment. 

Taking great care, first measure the mains voltage with a suitable meter and change VCAL so that your circuit gives a similar value.  Then check the current drawn by different loads which take known amounts of power and adjust ICAL so that your readings match these values.

Calibration is part of the Energy Monitor's design, you can't avoid it by calculation alone.  Calibration is the process that allows different circuits to give the same (correct) results.  

It is worth calculating the calibration constants, and you should use the calculated values as a starting point. You will almost certainly need to adjust the values (using the procedure described in http://openenergymonitor.org/emon/modules/emontx/firmware/calibration and repeated by calypso_rae above) to take account of component tolerances. But if you find that you need to change the calibration constant by more than 10 - 15% for VCAL, or 5% for ICAL, then unless you can explain the difference it might indicate a faulty component or an assembly error (or, if you are not using a proven design, a design error), and you should carefully check your work.

 Hello, 

I'm experiencing the same issue you were, with the CT sensor, I understand that the arduino is picking up a lot of noise and that's the reason why we are seing some values even when the sensor is disconnected.

My problem is that after putting all the components together I took a measurement of the circuit my notebook was connect ... and the measurements seemed legit enough, I was getting around 60 VA  ... and a reading of the voltage of around 230V, but after connecting other devices to the line ... the current didn't change the way it should (it should of been of around 7A) , it stayed at the same value, the only visible change was in the voltage drop.

Do you have any hints  about way this is happening?

BTW I'm using the YHDC SCT-012-000 and a 33ohm burden resistor.

Thanks ;)

Have you read the installation and calibration notes? Where have you installed the c.t. ?

To check the operation of any system that can measure current and voltage, I would start with the standard OEM V&I sketch. 

While supplying a known load, such as an old-style 40W light bulb, record the power (which is available as emon1.realPower).  Don't worry too much about the absolute value at this stage, just reverse the clamp and repeat the exercise.  All being well, you should get two equal values with opposite signs.  

Check for linearity; ten times the current should be recorded as ten times the power.   Adjust VCAL and ICAL to give the voltage and current values that you expect, not forgetting to confirm your values by calculation so far as is possible :)

I posted a tool recently at  http://openenergymonitor.org/emon/node/789  which allows indivual samples to be inspected.  These values are in ADC-units in the range 0 - 1023.  Make sure that you're using a reasonable amount of the range.

Until these basic aspects have been dealt with, I wouldn't take new hardware any closer to household wiring than the nearest 13A socket!

Thanks for your responses, I found what was the problem with my ct ... it was a.... my really stupid way of measuring... I installed the ct sensor on the extension cord which was powering my laptop ... without separating the phase from the neutral ... Thanks again ;)

Now that I can see it's working I would like to try and get rid of some of the noise my circuit is picking up...

And since for the moment it's on a breadboard I'm thinking to print a pcb and have all the components installed on it.

And I was also thinking of trying to calibrate the circuit  by making an average of n samples ... for a given load (like calypso_rae sugessted) and going from there ... but I haven't thought this thru yet  ... any suggestions are more then welcome :D

I wasn't suggesting that you should take the average of multiple samples.  Rather, that your circuit should give readings that look right for various different loads.  If your circuit is linear, then that should not be a problem. 

My Mk2 input circuitry is on a breadboard and is giving good results.  There's nowt wrong with breadboards, for short-term use, IMHO :)

There's nowt wrong with breadboards, for short-term use, IMHO :)

But there's anecdotal evidence that breadboards are more likely to give spurious readings when no current is actually flowing. A PCB with a good layout for the analogue department is more likely to give satisfactory results. Breadboards are excellent for what they're intended. It's horses for courses.

Unless you're using all-soldered connections, your voltage and current inputs will be arriving at the Arduino via its push-in connector strips.  The sockets on my breadboard inspire far more confidence than those on either of my Arduinos!

My current and power readings seem just fine with the breadboard.  Once the design has been fixed, I then rebuild everything onto stripboard.  I've never constructed a PCB.  My first attempt to do so would probably not be a pretty sight!

 I have another question :D

If anybody tried it, or knows how this works...or how it's supposed to work

I also have a chipkit max32 prototyping board with a pic32 on it, and I initially tried to have the monitor working on it ... but I kind of failed.

to program the max32 I'm using MPIDE which doesn't really get along so well with the OEM library and I don't really know what I should change in it the make it work ... 

What are you referring to here: "If anybody tried it, or knows how this works...or how it's supposed to work"? The chipKIT board?

I have not noticed anyone in the forums mention the chipKIT board - I think everyone here uses either the Arduino or our shop's emonTx, emonBase and emonGLCD.

Unless anyone else knows better, I think you have to take our code, understand how it works and then adapt it to use the libraries etc. that I presume are available for the chipKIT, and at the same time adjust the code to suit what I presume are different port allocations etc. I see the Digilent website claims that it is "Compatible with many existing Arduino™ code examples" but clearly not all.

You might find someone who can give more help on the chipKIT forum.

Yes, that's what I was referring to, the chipkit board.

Hi,

New member here with problem which I think most closely relates to this thread.

Some details;

•  Using a 30A CT with built in ballast resistor (62 Ohms I believe)
•  Using a Maplins AC-AC transformer, set to 9V output (measured 10.75 no load)
• The board 5V (from USB) is 4.8V
• The two reference voltages (potential dividers) are 2.4V
• The divided down AC voltage from the transformer is 0.997V

The output in the monitor window is;

41.62   44.00   54.56   0.81   0.95

That 54.56V is the problem I have, to get it close to the expected 230V I have to increase the voltage calibration factor to over 1000, I can’t see why?

Hello & welcome,

Are you using the emonTx PCB or an Arduino? I assume when you say "The two reference voltages (potential dividers) are 2.4V" that it's an Arduino. If it's an emonTx, there's your problem - they should be 1.65 V.  Otherwise, those voltages seem to make sense, though the final divided down voltage (0.997) is OK for an emonTx but low for an Arduino (the Arduino input range with a 5 V supply is 0 - 5 V, so 5 V p-p less a bit for component tolerances = 1.4 - 1.5 V rms or so. But that doesn't explain a factor of about 4.

Which sketch? I also assume you have got all the required libraries downloaded and installed in the correct places.

The library function reads the reference voltage and it should cancel in the maths, have you tried putting some Serial.print(....) debugging statements in to see exactly what the values are. First suspicions are vcc = readVcc();  What are you getting there for vcc? (It should be the supply in mV, I read 3342 on an emonTx).

I’m really sorry, I just knew that I would leave out some important info. Here are some more details;

• The board is an Arduino Mega2560 with an Ethernet shield
• I am using the 5V board supply (derived from the USB supply) as Vcc for the current / voltage resistor networks
• The measured voltage at the input to the Mega is 0.997V AC with a DC offset of 2.4V
• I am using the Voltage and Current sketch from the examples in the EmonLib download package from github
• Libraries are downloaded and in the correct places
• After adding some debug prints to EmonLib.cpp for readVcc() I see the Mega reference value of 1100 (+/- 2 bits).

I’m guessing it’s that board reference value that may be a large part of my problem?

I tried making the change detailed here in post #2, but that had the effect of dropping the value to zero for readVcc;

http://openenergymonitor.org/emon/node/668

Thanks very much for the help.

Edit: Your points about the reference voltage got me thinking, and I just found this (perhaps I should have looked here first, seems obvious now?), it seems I have a couple of choices for the internal reference, and I guess that it is currently defaulting to 1.1V;

http://arduino.cc/en/Reference/AnalogReference

I guess that to obtain full range of the A-D inputs I need to set the Arduino to a default reference of 5V?

• The measured voltage at the input to the Mega is 0.997V AC with a DC offset of 2.4V
• I am using the Voltage and Current sketch from the examples in the EmonLib download package from github

With the standard Voltage and Current sketch, there should be two ac signals at the Arduino, one for voltage and one for current.  A 1V ac signal, centred at 2.4V, sounds perfect for the voltage input; that's around 3V peak-to-peak.

Thanks for the reply, I think you are correct, but I now believe that the reference voltage being used by the Mega is too low at 1.1V, I was probably editing my post while you were replying?

With the Arduino Uno Rev 3, the default value of Vref appears to be 5V.  That ties in nicely with the standard front-end circuits which create signals that are centred around 2.5V.

Using a lower value of Vref (e.g. 1.1V) might well be a good idea because this would be better suited to the output of the CT which does not like being forced to generate high voltage values.  The components of the resistive divider that creates Vref would just need to be altered accordingly. 

Reducing Vref may be a more practical alternative than adding an amplifier stage.  I'm so pleased that my circuit is still on breadboard ...

I'm at work at the moment, but will play around with the AnalogReference setting this evening, if the default value of 5V works, then I will probably stick with that.

I detect some confusion about to creep in here. If the reference is set to 1.1 V, then the signal must swing between 0 V and 1.1 V. If it was centred on 2.5 V, the input was permanently above the 1.1 V reference (= 1023 counts, the maximum) except for a brief period on the negative-going peaks, and that explains your very low reading for the mains voltage.(I won't confuse the issue with explaining what the software high-pass filter did - but I can if you want me to!).

Your choices:

1. Change the reference to 5 V, and adjust the amplutude of the input signals (voltage and current) to just under 5 V peak-peak, centred on 2.5 V.
2. Stay with the 1.1 V reference, and alter the bias chain resistors so that the midpoint is set at 0.55 V, and possibly adjust the voltage input divider and the current transformer burden too so that you have a 1 V p-p input signal.

As Calypso_rae points out, the current transformer will behave better with a lower burden resistor and lower voltage output (i.e. you might need to use an external burden in parallel with the internal one to give the 1.1 V peak-peak output at the maximum current you want to measure).

There should be no problem with using the 1.1 V reference. It does make the analogue inputs a little more susceptible to noise pickup, but the software should perform better because the 1.1 V reference is stable so you have no need to switch references in the software to measure the 5 V supply - which the library does automatically - to ensure the input is calibrated correctly.

I think the idea of using a smaller value of Vref is an excellent one.  This aligns nicely with the size of signal that a correctly set up CT will generate.  The burden should be set to give an output signal of around 1V p-t-p when the current is at the maximum rating of the dump load (usually 3kW, or 12.5A).

(hope I'm not addiung to any confusion!)

Robert / Calypso, thanks for the replies.

So I’m back from work and I edited the setup() section of the sketch to add ‘analogReference(DEFAULT)’, but the results didn’t change. I had added some debug print to the Emonlib.cpp, printing out the ‘result’ from readVcc(), and it did not change from the 1100 value I saw earlier. I suspect that this line may be incorrect;

ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);

But the suggested change here http://openenergymonitor.org/emon/node/668 did not work for me as it caused the readVcc() result to drop to -1.

I set the readVcc result to a fixed value of 5000, i.e. meaning full digital range equates to 5V (not quite the true value) and I started getting sensible values for both voltage and current, my 3Kw electric kettle adding about 12A to the current reading when turned on.

So, I think the analogue reference is actually defaulting to the 5V supply, and A-D conversions are good with no clipping, but the Emonlib.cpp readVcc() function is always returning the internal 1.1V reference value.

I could change resistor values as suggested, but would like to try to track down the correct code for determining the analogue reference voltage in use by the Mega 2560.

I’ve been looking at the datasheet, and it looks to me like I should be able to set the ADMUX to read the AVCC voltage, but I’m not familiar with the code to set the appropriate bits. I should be able to work it out, just bit too late in the day for me to think straight right now.

http://www.atmel.com/dyn/resources/prod_documents/doc2549.PDF

From what you say, I think you're right and it is only the reading of the reference that's gone wrong. If your 5 V is very stable, then in theory at least you shouldn't need to read it and you could plug in the fixed value and forget it. If not, the reading of it is probably necessary.

I suspect the code you tried was for the 328P, which is the one used in the emonTx. That could explain why it's all not working, because stuff like _BV(REFS0) are macros and could well be device-specific. I've never had to delve into these areas, I think there are three approaches you could try:

1. Find a library specific to the 2560 to read the reference, or
2. Track down in the library you're using the routine where this is set, compare the two data sheets and make the appropriate changes, or
3. Write the command to read the reference from scratch from information in the data sheet and/or from the app. notes at: http://www.atmel.com/devices/atmega2560.aspx?tab=documents  This one: Atmel AVR126: ADC of megaAVR in Single Ended Mode  looks helpful.

You might find the explanations here useful: http://urbanhonking.com/ideasfordozens/2009/05/18/an_tour_of_the_arduino... and Trystan Lea recently blogged about a linked topic here: http://openenergymonitor.blogspot.co.uk/2012/08/low-level-adc-control-ad...

Thanks,

It was getting late last night, and while the datasheet isn’t so difficult to understand it was too late for me to investigate any further.

I measured the AVCC at the pin, and it was very stable (4.765), so I entered that adjusted value (4765) into Emonlib.cpp, and I seem to be getting sensible values e.g. switching on the kitchen lights (8*50W halogen) caused the power reading to increase by 400W. I still need to make some calibration changes, but I don’t mind that now that I am in the ballpark and not out by a factor of nearly five. I’m testing with the board powered from my laptop USB port, so will need to make another adjustment when I move to a different supply or computer.

I will consider using a lower reference voltage (maybe the 2.56V ref), but I plan to use the other 14 analogue inputs for measuring things like room temperatures/light/humidity around the house, and the sensors I plan to use are very simple to interface to a 5V range D-A. Also with a number of sensor cables (screened) distributed round the house I think the affects of noise could become more significant if using a lower reference voltage.

Knowing what I know now I am surprised it worked at all, most of the input waveforms must have been clipped by the A-D. That does seem to explain the occasional zero readings and the occasional 20Kw readings, it's all pretty stable now.

So you're a moderately happy bunny then?  Long-term I think it would be a good idea to track down where the error is and read the reference, because then you shouldn't be bothered if the 5 V drifts a little.

What version of the ATMEGA 2560 chip are you using?

Looks like the "A" version has some ADC bugs in it!

http://www.scribd.com/doc/49801593/133/ATmega2560-rev-A

4. Internal ADC reference has too low value
The internal ADC reference has a value lower than specified.
Problem Fix/Workaround

- Use AVCC or external reference.- The actual value of the reference can be measured by applying a known voltage to theADC when using the internal reference. The result when doing later conversions can then becalibrated

 

Robert,

Yes I’m happy. If I do find anything relevant / useful I will post here, but at the moment I’m good to go.

Stuart,

Not sure which version it is, but I was able to select the different reference voltages (internal 1.1 / internal 2.56 / AVCC) and measure the change at the pin, and the results for the current / voltage measurement also changed at the same time. So I think the internal reference voltages are good, it just seems like the code at the end of Emonlib.cpp (readVcc) is not working with the Mega2560.

Andy,

the ATmega2560s ADC and especially its multiplexer is quite a bit different from the ATmega328. It has more input channels and an option for differential inputs.

You have to change at least one line in readVcc()::

  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
to

  ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);

This should select the 1.1V reference as ADC input on the ATmega2560 same as the previous line did for the ATmega328.

I can't try this because I do not have an ATmega2560.

BR, Jörg.
 

Jörg.

I have tried making changes such as you suggest, and in fact with the current Emonlib.cpp unchanged I have verified that the 1.1V reference is being selected / read. However following the original energy monitor instructions here; http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor I have everything set to operate from a 5V supply, so if I were to set the ADC with a top end reference of 1.1V without modifying the circuit, everything would be clipped quite heavily.

I currently have the Mega2560 set to use the AVCC reference which is pretty stable at 4.675V, but this will most likely change when I change supply. The remaining problem is that the readVcc function in Emonlib seems to assume that the reference voltage in use is the 1.1V ref, and accordingly all my signals were being factored down roughly five time e.g. mains voltage was reading about 55V. The reference voltage in use is AVCC, nothing is being clipped, but the Emonlib readVcc function is in my case making an incorrect assumption.

If it is possible, and I think it is, I plan to change the Emonlib readVcc function so that it reads the AVCC voltage, then I should be able to change supplies e.g. move to a different computer without having to use a preset value in the readVcc function as I am currently doing (always returns 4675).

The remaining problem is that the readVcc function in Emonlib seems to assume that the reference voltage in use is the 1.1V ref,

No, the readVcc() function 'compares' the reading of the 1.1V reference to VCC in order to get a 'calibrated' value for the (until then unknown!) VCC voltage (if VCC is taken as reference for the ADC, then FullScale of the ADC = VCC = 1023).

Example:

if VCC = 4.4V (=1023=FullScale of the ADC!) then the reading for the reference voltage of 1.1V will be ~1023/4=~256. So, if you do not know the value of VCC, you take the result of the ADC conversion of the 'well-known' 1.1V and use this value to calculate VCC. In my example:-

- you get a reading of 256 for 1.1V

- calculate Vcc as 1023/256*1.1V = ~4.4V

The 1.1V reference voltage does not have a very good absolute accuracy, but it is quite stable regarding temperature and VCC changes. So, using this method makes the voltage readings independant from supply voltage fluctuations and temperature changes.

if VCC = 4.4V (=1023=FullScale of the ADC!) then the reading for the reference voltage of 1.1V will be ~1023/4=~256.

It may be that I have misunderstood what readVcc is trying to do. I’m working from memory since I’m at work at the moment, but I have only seen readVcc return either 1100 or -1, regardless of what I set analogReference() to in the sketch (DEFAULT, INTERNAL1V1, or INTERNAL2V56).

I know that currently I have set readVcc to return a constant value of 4657, with the analogReference set to (DEFAULT), and AVCC measuring around 4.657V at the appropriate pin on the Mega2560. This results in sensible values for power / current / voltage being printer out to the monitor window.

If however I let readVcc report as normally without making any other changes, it returns a value of approximately 1100, which I understand means Vcc is 1.1V, and all values printed out to the monitor window are wrong e.g. Vrms is about 55V.

So my understanding of what you have said, is that for a normally working system the readVcc function should only return a value of around 1100 if the ADC reference voltage is set to 1.1V, and if the reference voltage for the ADC is set to 5V then readVcc should return a value of 5000. Does that seem correct, if so it's not what is happening for me?

If you use readVcc() as it is, it does not matter to which other value you set the reference with analogReference, as this is overwritten in readVcc(). ADMUX = _BV(REFS0) sets the reference to 'AVCC with external capacitor on AREF pin'.

And yes, this function:

long EnergyMonitor::readVcc() {
  long result;
  ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  delay(2);
  ADCSRA |= _BV(ADSC);
  while (bit_is_set(ADCSRA,ADSC));
  result = ADCL;
  result |= ADCH<<8;
  result = 1126400L / result;
  return result;
}

should give a reading of ~5000 from readVcc() if your VCC is ~5.0V.

Thanks Jörg,

I will have another look tonight if I get chance and add a few more print statements to see where it goes wrong. I have tried adding _BV(MUX4) already and it didn’t work (result was -1), but I will happily try again since I could have made a silly error in my typing.

Well I tried the code change again, even copied/pasted from web pages where I had seen the same code, the result was -1 as before. With the original code the result is 1100, and so it seems to me that the measurement is being made while the reference voltage for the ADC is also 1.1V, a bit odd since all other measurements seem to be correctly scaled for a 5V range, simply forcing readVcc () to return 4675 results in reasonable values for voltage / current. So is it possible that the readVcc() function is not only measuring the 1.1V reference, but is also setting the ADC to use that reference at the same time? I don’t see how myself.

As I understand it, the way it should work is this:

1. Change the ADC to use the 1.1 V internal reference.
2. Switch the multiplexer to look at the External Reference / supply
3. Let the reference settle for 2 ms.
4. Measure it.
5. Put everything back.

Robert, that makes sense, and I think agrees with Jörg’s explanation above. I believe the Mega2560 is using the 1.1V as both the reference for the ADC and the MUX is measuring that same voltage (a bit incestuous). The raw ADC output is 1023 (ish) giving a readVcc() return of 1100 mV.

Actually, thinking about it, I can’t really tell what reference it is using for both; they could both be the AVCC voltage since if both the reference and the measured voltage are the same the result will be 1023.

It seems to me that I need to change the code so that readVcc() uses the AVCC (5V) reference to measure the 1.1V reference, which should result in the area of the figures Jörg suggested (225 for as 5V reference). I need to think about this more in the morning when my brain is awake, it's a little late for me to be looking at datasheet registers.

EDIT:

I think the answer may be on page 291 of the Mega2560 datasheet, Table 26.4 MUX5:0 row 011110 1.1V (VBG), I need to set the MUX bits to 011110 to select the 1.1V reference to be measured (with AVCC selected by ADMUX = _BV(REFS0) as Jörg said.

I need to set the MUX bits to 011110 to select the 1.1V reference to be measured (with AVCC selected by ADMUX = _BV(REFS0) as Jörg said.

This is exactly what the line

  ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);

does! MUX5 is per default set to 0, but you could do this manually if you do not trust it. Did you really try this code line (or better still the complete code for readVcc() that I posted above)?
 

Does ADCSRB (in the 2560) need to be set up as well as ADMUX ? It doesn't exist in the 328.

Jörg, yes, I really have tried that line, several times now, manually entered and cut/pasted from web pages, the returned value is -1, I have even tried setting MUX5 explicitly (a different register - ADCSRB) but admit I may have got that bit of code wrong.

Robert, if the ADC is set to use the AVCC reference, with the MUX incorrectly set such that it’s reading a floating input, or worse the ADC set to the 1.1V reference with the MUX incorrectly set to a floating input, then I think that could be a possible cause for the full scale reading?

Jörg, yes, I really have tried that line, several times now, manually entered and cut/pasted from web pages, the returned value is -1, I have even tried setting MUX5 explicitly (a different register - ADCSRB) but admit I may have got that bit of code wrong.

Hmmm. I give up, no chance to test it myself :-(

-1 is a strange result. How can this be reached? If you divide 1126400L by a positive integer in the range from 0-1023, you should never get -1.

STOP, divide by 0 could be a reason! So it seems that the ADC conversion gives 0 as result!?!

ADCSRB &= ~(1<<MUX5) clears the MUX5 bit. If this is set, strange things might possibly happen.

I think it's anybody's guess what a floating input will return. There's absolutely no reason for it to float anywhere in particular, the input impedance is huge (100M Ohms) and flux residue or dampness on the PCB is going to have as much effect as anything. The chances are though it will float to one rail or the other.

So yes, a floating input could give you full scale. Or maybe not!

A snippet of code here: http://bennthomsen.wordpress.com/embedded-design/peripherals/analogue-in... suggests that ADMUX and ADCSRB both need to be set:

1	uint16_t read_adc(uint8_t channel){

2	ADMUX &= 0xE0;           //Clear bits MUX0-4

3	ADMUX |= channel&0x07;   //Defines the new ADC channel to be read by setting bits MUX0-2

4	ADCSRB = channel&(1<<3); //Set MUX5

5	ADCSRA |= (1<<ADSC);      //Starts a new conversion

6	while(ADCSRA & (1<<ADSC));  //Wait until the conversion is done

7	return ADCW;}         //Returns the ADC value of the chosen channel

Thanks Jörg / Robert, I will take another look at it this evening, but not too late in the day this time.

If MUX5 is the only bit in question, then since it can only be one of two values, the incorrect code that might result would be 111110 which in table 26-4 of the datasheet is listed as ‘reserved’.

Andy,

can you paste this:

long EnergyMonitor::readVcc() {
  long result;
  ADMUX   = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  ADCSRB &= ~(_BV(MUX5));
  delay(2);
  ADCSRA |= _BV(ADSC);
  while (bit_is_set(ADCSRA,ADSC));
  result  = ADCL;
  result |= ADCH<<8;
  result  = 1126400L / result;
  return result;
}

and give us the result? If this does not work, than we simply miss something that might have nothing to do with the mux or reference settings.

A snippet of code here: http://bennthomsen.wordpress.com/embedded-design/peripherals/analogue-in... suggests that ADMUX and ADCSRB both need to be set:

Sorry, Robert, that link doesn't work for me :(

Where are the bit-setting values that appear in the EmonLib function readVcc() actually defined?

Robin,

if you talk about MUX1, REFS0, these are defined in the header files for the individual controllers. In my arduino installation I find these at

arduino-1.0.1/hardware/tools/avr/avr/include/avr/iom328p.h

in this case for the ATmega328.

Jörg, I’ll gladly try that, will be about 10 hours from now though, and will let you know how it goes.

Thanks Jörg.  As posted, my code doesn't #include any other files, and doesn't use readVcc().  Because V & I measurements need to run continuously, there is no proper time for this.  Rightly or wrongly, my sketch seems to work fine without it!

Yesterday, I changed the analogReference to INTERNAL.   My V and I signals are now much smaller in order to stay within the 1.1V range of the Uno's ADC.  I've not recalibrated anything, and still don't use readVcc(). 

Today, the triac appears to be behaving just as before, and our water is clearly getting warm.

Robin,

readVcc() does only make sense if you think that your VCC is not stable (enough). As it is only measured every now and then it can also not correct very short term VCC variations.

With a stable VCC provided by a voltage regulator it is simply not necessary. (I think they may have introduced it because the arduino hardware may be powered by USB where the voltage can vary quite substantially.)

Hello, yes the reason readVcc was introduced was primarily to make it possible for the emontx to "self-calibrate" as the supply voltage decreased from 3.3V to 2.7V when powered directly off batteries. If your confident that the voltage is constant then I guess it is not needed. All the best, Trystan

Jörg, that worked perfectly, seems my error was with MUX5, thanks to everyone for the help, very much appreciated.

Good to hear that it works now .