Archived Forum

Hints:

1. Check your assembly - component values, orientation of polarised components once more.
2. Check you have the correct sketch.
3. Check your voltages. Do you have approx 2.5 V d.c. on the positive end of C10? Do you read the same voltage on the Arduino IO ADC0 (ATMega pin 23 I believe)? Do you read approx 1 V a.c across R14?

Ah... find the problem. I am trying to measure AD0 and AD5 using analogRead. This seems to mess up the emonlib somehow making the readings inconsistent.

Need a hint here how to read AD0 and AD5 (AD0 disconnected from Vrms circuit). The need behind this is to read the LifePO4 battery voltage and current for battery management.

currentB = (float)((10*5*analogRead(current_AD)/256)*(5/Vcc))-100;
voltageB = (float)10*analogRead(voltage_AD)/256;

You say you are trying to use emonLib? emonLib does not include support for the emonTx shield. If you look at the place where the pin numbers are substituted for channel numbers, you will see 3 only:

You need to change your copy of emonLib (and call it by a different name!). If you look at the code and the table, all should become clear.

Try using the emonTxShield examples that are in the enonTx repository, they have got the emonTxShield pin mappings and correct calibration built in: https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxSh...

Thanks chaps - i guess we are now talking about different things. A) got emonshield working after removing analogRead() from my code, B) can not find a way to use analogRead(5) when emonlib is running. Using analogRead() inside void() makes emonlib unstable with inconsistent readings. Need analogread to be able to measure battery voltage and current. Please advice how to use analogRead() with emonlib ???

I don't understand your problem. What do you mean by void( )?  "void" defines the return type of a function. You cannot name a function "void". I don't know which compiler you are using, mine complains if you try.

I need to see your code, because there should be no reason why you cannot read an analogue input independently of the calls to the library methods.

You aren't trying to use a c.t. input to measure battery current, are you?

In a way I am trying to use emonlib Vcc input (ad direct connection to AD0) and the free AD port 5 to read analog data (The Vcc input is disconnected on PCB).

I can make the emonshield work as a standalone and give reliable CT1 values. Also the can read the battery voltage (using a voltage divider) and current (using ACS758 chip) using normal arduino uno script.

When adding analogRead(0) or analogRead(5) to void loop() (which we used to call main() some 20 years ago) it all becomes a bit of a mess.

You can try the same by just adding any analogRead(5) to the void loop() and check what happens to the output of the ct1.calcIrms(1480) function and what the analogRead(5) returns compared to when these two are run in different scripts. Something odd happens when putting analogRead() to the emontx script.

I must be doing something wrong...????

Basically the code is...

#define FILTERSETTLETIME 5000                                           //  Time (ms) to allow the filters to settle before sending data
const int CT1 = 1;
const int CT2 = 0;

...

void setup()
{
if (CT1) ct1.current(1, 111.1);                                     // Setup emonTX CT channel (channel, calibration)
if (CT2) ct2.current(2, 111.1);

...

void loop()
{
     if (CT1) emontx.power1 = ct1.calcIrms(1480) * 240.0;
 

     //
    // Read battery voltage and current
    //
    currentB = (float)((10*5*analogRead(0)/256)*(5/Vcc_psu))-100;
    voltageB = (float)10*analogRead(5)/256;
    delay(10);
 

      Serial.println();
      Serial.print("V=");
      Serial.print(voltageB,1);
      Serial.print("   A=");
      Serial.print(currentB,1);
      Serial.print("   W=");
      Serial.print(voltageB*currentB,0);
      Serial.print("   CT1=");
      Serial.print(emontx.power1);
      Serial.println();

Can you attach the whole sketch as a file please?

Will - do, posting the code when at the desktop.

What I gather about the problem is that there is not adequate time for the port to settle between changing the ports as what I read the analog read is really first setting multiplexer and then reading the port. According to some articles reading the analog port twice settles this problem. Anyway as there does not seem to be a way to control when the CTx analog reads within emonlib are happening dont know how to test if it is this analog port multiplexing problem that needs fixing or if its something else.

Anyone else ever trying tying to read other analog values than Vcc and CTx ?

Just a thought.

http://www.adafruit.com/blog/2010/01/29/how-to-multiplex-analog-readings-what-can-go-wrong-with-high-impedance-sensors-and-how-to-fix-it/

Attached is one version of the code which has been used for testing.

If the analogRead:s are commented out the CT1 information looks consistent (within AD converter tolerance). If and when analogRead:s are uncommented/active the CT1 information is messed up.

Note: On emonTx shield the path to AC voltage circuit is cut for analogRead(0), so its not a hw issue.

You needed to tick "List" when you attached the file.

We have identified a hardware problem that only (I think) occurs with the 'floating' c.t. as in the emonTx and the emonTx shield (but not in the SMT emonTx) where the sample & hold capacitor acts as a charge pump and transfers charge from one input to the next via the multiplexer. The effect is very small, however.

There is a known problem when changing the voltage reference for the ADC converter, which requires a delay to allow it to settle, but you are not doing that.

The link to the comment about high impedance sensors only repeats the warning in the Atmel data sheet. If your voltage divider resistors are sensible values, I cannot see that being your problem, if the smaller is >100 kOhms, it might be worth reducing them. The current sensor output is surely a low impedance source (unless you have a high value series resistor in the low-pass output filter), so again that is unlikely to be the problem.

You are using the latest emonLib?

I can't see a problem with your code. I'm using a standard emonTx, and I cannot reproduce your fault. I have run your sketch (but with the battery voltage check in emontx_lib - emontx_sleep commented out) and the readings are unchanging, I cannot see any change in CT1 whether ADC5 is being read or not, and what value it is reading, 0, 20 V or 40 V (corresponding to 0 V, 1.65 V or 3.3 V on the input pin)..

Then I tried a minimal sketch only reading the two inputs direct and the c.t. via the library. Again, I see the same numbers for CT1  whether ADC5 is being read or not.

I'm afraid I can't see what your problem is.

Found a solution, the whole use of emonlib and analogRead must be turned to be timer controlled instead of using the main loop. Attached a working script which is not elegant by any means, but it works without reading fluctuation.

Figuring this out made me think that is there a bug in how emonlib is built. Its a continuous loop making measurement cycles somewhat variable if there are components added that slows the process down like analogRead(). Looks like how the current design how emonlib usage is generally used makes it vulnerable for timing issues. This is a worrying discovery.

Would appreciate any comments about the above finding.

EDIT - just saw R.W.:s answer. This made me think that we have differences in the libraries we use promoting timing issues somehow. How to check that ?

The method you are using in emonLib counts a fixed number of cycles (that you define in the call) and returns the rms current measured over that period. This was clearly intended for the battery-powered emonTx, which is then put into low-power sleep mode for 5 s until the current is sampled again.

I think the problem is that you did not understand how the library works, and you were attempting to use it in a way that was not intended.

RW, referring to my incompetence, could you (or someone) describe how emonlib is intended to be used in case one wants to use the same script for both emonlib energy monitoring and analogread for third party devices ???

Petri,

Not getting into the brain of the designer, or not knowing the history of a device or a development, doesn't amount to incompetence in my book, it could be for the very simple reason that you didn't have the time. I didn't say you were incompetent, so there's no need to get agitated.

For the record, I agree that documentation is lacking in some areas, and over the months that I have been involved here, I have been trying to address that problem. If you see any areas that you think need attention that I haven't spotted, feel free to draw it to my attention.

I think I've addressed the question of how emonLib was intended to be used. There are many current threads discussing timed and interrupt-driven methods of reading the analogue inputs, and you must be aware of these.

No offence taken or given. Just would like to know how this is designed to work for the above mentioned setup ? What version of libraries are latest ? Any sample scripts using emonlib and analogRead ? Sorry but lost here (and really feel incompetent for this subject ;-) - what threads, did not found when tried searching ?

The original emonTx was designed to be powered by battery or mains. I believe the battery version came first. When mains powered, an AC-AC adapter can be used to monitor the mains voltage and derive an accurate measure of power, real and apparent. If battery operation is required, only current is sensed and an estimate of power based on the usual supply voltage is transmitted. In this case, battery life is important so the software reads a defined number of samples, calculates the rms current over that period and transmits the result. The software then sleeps the processor in low-power mode for 5 seconds. When the voltage input and true power calculations were added, and I suspect partly also to minimise use of the R.F. channel (which has a limitation that each transmitter can broadcast for not more than 1% of the time), the same algorithm was retained, except that the period is defined in complete mains cycles.
Thus, when you call any of the emonLib functions to read current or power, you are reading the average over a period of several cycles.

I don't know which library versions are latest - I've been pressing for a version control system to be introduced for some time, but it appears to be low on the priority list. I have TortoiseGit installed and simply "pull" regularly.

There are currently two designs 'live' that do things differently (and don't use emonLib). There is Calypos_rae's Mk2 (http://openenergymonitor.org/emon/node/841) and its successor the Mk2a  (http://openenergymonitor.org/emon/node/1681) and MartinR's Phase-locked loop (http://openenergymonitor.org/emon/node/1535). Both have spawned variants that extend the original idea, Series530's "Fusion" (http://openenergymonitor.org/emon/node/1103) amongst them.  These monitor the power continuously, sampling the mains upwards of 40 times per cycle. From the code you posted, these might be more applicable to your application.

Excellent - thank you, now understanding the history all this starts to make sense how code was intended to be used - disabling the sleep period is not enough, need to look the core concept too. Looks like I have a lot of code reading to be done to get my own project to the correct route. While talking about the solar my 1-wire network for heatpump monitoring just collapsed so I guess fixing the wiring and reinstalling sensors is priority during coming days.

Here is what I tested today using the sample voltage current script. Would be enclined to say that the timer based reading seems to be more accurate than using standard sample script (even without using the analogRead at all). The load is a normal lightbulb which should not vary much, voltage tested with multimeter is stable like when using the timer base script. This is the baseline in defining how to move forward.

What makes me curious though is that RW said he did not have variances to the readings when introducing analogRead() to the standard script ? Anyone else capable of validating the accuracy improvement when using timers ?

My emonlib is now about a month old and using Arduino 1.0.1.

1. Standard script

void loop()
{
  emon1.calcVI(20,2000);         // Calculate all. No.of half wavelengths (crossings), time-out
  emon1.serialprint();           // Print out all variables
// Serial.print(analogRead(5));
}

rP=89.93 aP=91.06 Vrms=227.32 Irms=0.40 PF=0.99
rP=93.49 aP=94.59 Vrms=229.48 Irms=0.41 PF=0.99
rP=90.84 aP=91.92 Vrms=227.95 Irms=0.40 PF=0.99
rP=92.25 aP=93.45 Vrms=229.53 Irms=0.41 PF=0.99
rP=90.40 aP=91.53 Vrms=227.44 Irms=0.40 PF=0.99
rP=92.17 aP=93.37 Vrms=229.64 Irms=0.41 PF=0.99
rP=89.97 aP=91.11 Vrms=227.34 Irms=0.40 PF=0.99
rP=92.48 aP=93.76 Vrms=229.42 Irms=0.41 PF=0.99
rP=90.91 aP=92.04 Vrms=227.71 Irms=0.40 PF=0.99

2. Standard script with analogRead() included - produces serious amount of variance and not useable

void loop()
{
  emon1.calcVI(20,2000);         // Calculate all. No.of half wavelengths (crossings), time-out
  emon1.serialprint();           // Print out all variables
  Serial.print(analogRead(5));
}

488rP=93.51 aP=94.69 Vrms=230.17 Irms=0.41 PF=0.99
430rP=133.23 aP=135.03 Vrms=275.63 Irms=0.49 PF=0.99
507rP=87.82 aP=88.98 Vrms=221.76 Irms=0.40 PF=0.99
433rP=132.20 aP=134.04 Vrms=274.31 Irms=0.49 PF=0.99
500rP=89.92 aP=91.11 Vrms=225.24 Irms=0.40 PF=0.99
433rP=131.14 aP=132.80 Vrms=273.70 Irms=0.49 PF=0.99
500rP=91.08 aP=92.19 Vrms=225.17 Irms=0.41 PF=0.99
430rP=132.15 aP=133.87 Vrms=275.47 Irms=0.49 PF=0.99
497rP=89.71 aP=90.99 Vrms=225.82 Irms=0.40 PF=0.99

3. Modified he emon.calcVI to be called on regular intervals using a timer and when analogRead() is running disabled using emon.calcVI. (Script attached, using a spare 9V AC supply for testing which outputs 'only' 9.6VAC so thats different conmpared what you others may have. Also ports are for emonshield not for emonTX.) There is an odd Irms reading fluctuation/error there which dont undestand where it comes from - and it does not seem to affect rP and aP readings at all ?

//
// Timer interrupt based call to emonlib to calculate VI.
//
ISR(TIMER2_OVF_vect) {

    if(!timeractive)
    {
    timeractive=0xFF;
    TCCR2B = 0x00;
   
    emon1.calcVI(20,2000);         // Calculate all. No.of half wavelengths (crossings), time-out

    TCNT2 = 130;    
    TIFR2 = 0x00;  
    timeractive=0x00;
    TCCR2B = 0x07;
    }

   
};

void loop()
{
  emon1.serialprint();           // Print out all variables
     if (!timeractive)
    {
      TCCR2B = 0x00;
      Serial.print(analogRead(5));
      TCCR2B = 0x07;
    }
}

418rP=94.42 aP=95.38 Vrms=228.31 Irms=0.42 PF=0.99
361rP=94.11 aP=95.06 Vrms=228.62 Irms=0.42 PF=0.99
368rP=94.92 aP=95.87 Vrms=227.81 Irms=0.42 PF=0.99
367rP=93.89 aP=94.88 Vrms=226.88 Irms=0.53 PF=0.99
412rP=93.93 aP=94.88 Vrms=227.82 Irms=0.42 PF=0.99
425rP=94.26 aP=95.23 Vrms=227.60 Irms=0.42 PF=0.99
427rP=94.47 aP=95.40 Vrms=227.44 Irms=0.42 PF=0.99
378rP=93.40 aP=94.43 Vrms=227.29 Irms=0.42 PF=0.99
356rP=94.62 aP=95.55 Vrms=227.33 Irms=0.42 PF=0.99

I don't understand what you are trying to do there Petrik. You have an 8ms timer interrupt but you call emon1.calcVI() for 20 half cycles which will take 200ms inside the interrupt. This will just block other interrupts for 200ms.

Havent had time yet to check how long the calculations take. My aim is simple want to be able to use analogRead() for measuring PV voltage and PV current. Using the standard emon library it does not work in my setup. Readings are inconsistent and even stanard methods promote variance. Need to look for altenative approach, using timer is one.

the calcualtion is 20 x 10ms = 200ms

Your problem may be the print statements, which use interrupts, interfering with the I/V sampling. Try putting a delay in the loop after the prints.

With the timer interrupt you are effectively disabling interrupts during the sampling so the problem goes away.