Archived Forum

The voltage check at startup is just that - a quick check to test if the ac adapter is present. It's not calibrated at that point, so nothing to worry about.

Do you have a single phase or a 3-phase supply?

Is your sketch the one you used originally a year ago, or did you download it from GitHub recently?

Which AC adapter do you have? The default Vcal is for the UK Ideal adapter, if you have a different one (the Euro plug?) then you need a different calibration coefficient (see http://openenergymonitor.org/emon/buildingblocks/calibration). But in any case, those are only "factory spec" values and component tolerances will mean the Vcal you need to give the correct voltage is likely to be different.

But reading 15 kW (10 kW with the voltage corrected) is worrying if you are not consuming much power.
Which CTs are you using? Again, the Ical values are for the YHDC-013-000 and subject again to tolerances. If you have a different CT or a different burden resistor, then those calibration coefficients will be wrong.

Ah okay, I'll ignore the 197V then.

These are the ACs from the shop with a Euro connector (IDEAL DE-06-09). It's a single phase setup with 4 CT's. These are the YHDC-013-000 from the shop so the calibration should be okay, right?

What I find strange is that they worked before, just like the other two EmonTX3's which are hanging next to this one (stil running the old config). I briefly switched the AC adapter form another TX but that didn't change a bit.

The Vcal for that ac adapter is 260.0 - not greatly different. The CTs should be right too (but I had to ask!) Something is different, that's for sure.

Do you know what the actual current (or power) is - knowing that would help me.

Is your sketch the one you used originally a year ago, or did you download it from GitHub recently?

Have you changed or updated the EmonLib library? The reason for considering that is the calibration for the ADC reference is in there - and that affects both voltage and current calibration.

I've used the sketch of last year but used a recent EmonLib library... I just switched back to an older EmonLib library (had too dig in my archieves) and this resulted in the correct values again. Thanks!

Now I do wonder, what has changed in EmonLib so that I can use the updated libraries?

That's what I'm wondering too! I'm not aware of anything substantial - unless your library predates the emonTx V3, when a switch to use a fixed value for the reference calibration was introduced as a result of the V3 using a regulated supply even when running on battery.

The present emonLib should give you the correct values with the present sketch.

A thought: do you have a very old emonLib anywhere on your machine? The reason I ask is this: The Arduino IDE uses a weird method to find libraries. It does not appear to follow the normal rules that most compilers and linkers follow, it is capable of finding a library that you have moved and renamed. The only certain way I know to defeat that behaviour is to zip the library and delete the uncompressed version, renaming the directory is not enough.

If you can post your sketch, I'll check it, because I don't understand the mechanism that caused your problem.

(not sure what happened to previous post so I'll retry)

I've attached the emonLib from November 2014 (EmonLib-master.old) that does work and the current emonLib (EmonLib-master.new) where I get the strange values.

The sketch I'm using is also attached (emonTxV3_RFM12B_DiscreteSampling.ino), it's basically the default sketch with some inverse for some CT's which I mounted wrong.

Your 'big' post was held for moderation. There are no differences in your sketch to explain the problem, but there are differences in emonLib. Your 'old' version uses a hard-coded "1023" for the ADC resolution, whereas the new uses "ADC_BITS" = 10 or 12 depending on the processor. That is set in emonLib.h, so the question: was the power wrong by a factor of 16 (2 bits squared - for power) and could it have picked up that your ADC was 12-bit, i.e. an Arduino Due?

I think that has to be the explanation, because I've compiled your sketch (having put some print statements back in!) with my (the same as your new) emonLib library, and I get the correct voltage and current.

Here's a trick that I do when I want to take print statements out:
At the top of the sketch, I put "#define PRINT"
Then around each print statement, or set of print statements, I put
#ifdef PRINT
.... the print statement(s)
#endif
then to remove the print statement - they're not even compiled - I comment out #define PRINT

I briefly had an Eureka! moment, it worked. But no matter what I change in the emonLib library the Arduino IDE doesn't seem to pick it up (I've restarted the IDE)? Only when I overwrite the file with a copy action it is picked up..

I haven't removed the print statements for as far as I know. Is there a way to get some output from the emonLib.cpp code? I'd like to read the ADC_COUNT value and see what differences there are.

Sorry, I'm not with you there. Do you mean changing the library had no effect? Are you sure you have only one copy (in source form) anywhere on your machine? Remember what I wrote about the IDE finding it anywhere! And restart the IDE means close down ALL the IDE windows and running instances, leave one open and it doesn't forget the old version!

You can put:
Serial.print("ADC_COUNTS=");Serial.println(ADC_COUNTS);
in your sketch - anywhere as long as it is after Serial.begin( ). But you haven't got ADC_COUNTS in your old library.

Sorry, I was a bit unclear. Yes, it seemed as if the IDE didn't pick up any changes. But I made (another) rookie mistake, there was another piece of code that caused the weird values (and I didn't notice the code). 

PS: I closed all IDE's (on a Mac that's pretty easy)

It turned out not to be the ADC_COUNTS part (which is 1024 by the way) but the following code:

 // Initialise filter values (otherwise these will be random at power-on) https://github.com/openenergymonitor/EmonLib/issues/4
    filteredV = sampleV = analogRead(inPinV);
    filteredI = sampleI = analogRead(inPinI);

Removing that from emonLib.cpp results in normal values again. But as it says, it's added because of an issue. But adding this causes an issue for me...? Could this be the result of having older hardware?

PS: I'm using the current sketch for emonTX3 (not 3.4)!

I looked into that problem a long time ago and it's not as easy to resolve as Jack seems to think. The solution I suggested, which was to run the filters for a few iterations on startup and is implemented in the demo sketches, is a lot safer. I'll write to Glyn and point out that you've had problems.

I suggest you take those lines out, especially if you've proven they are causing trouble.

You need to use the "V3" sketches for the V3.2, and only the "V3_4" sketches for the V3.4, on account of the changed radio module (from RFM12B to RFM69).

OK, I've added in the lines that are in the latest emonLib (1a654efaca) and I concur, EMONLIB IS BROKEN

Here is what I get with the "initialisation":
Node: 10 Freq: 433Mhz Network: 210
13936 31168
13929 31189
13943 31146
13925 31120
14554 31733
14583 31756
14538 31723

(The first column is power - should be zero, the second column is Voltage in hundredths - should be 24000.)

And here is the same without those lines in the library:
Node: 10 Freq: 433Mhz Network: 210
7 23878
3 23928
5 23932
6 23945
4 23931
2 23928
3 23979
showing the correct power and voltage.

[Edit]
The following lines, still present in the example sketches, achieve the desired result in a much more satisfactory (if slightly more time-consuming) manner:

// Do some measurements to allow the software filter to settle - don't use the result
if (ACAC)
{
if (CT1) for (int j=0; j<5; j++) ct1.calcVI(no_of_half_wavelengths,timeout);
if (CT2) for (int j=0; j<5; j++) ct2.calcVI(no_of_half_wavelengths,timeout);
if (CT3) for (int j=0; j<5; j++) ct3.calcVI(no_of_half_wavelengths,timeout);
if (CT4) for (int j=0; j<5; j++) ct4.calcVI(no_of_half_wavelengths,timeout);
}
else
{
if (CT1) for (int j=0; j<5; j++) ct1.calcIrms(no_of_samples);
if (CT2) for (int j=0; j<5; j++) ct2.calcIrms(no_of_samples);
if (CT3) for (int j=0; j<5; j++) ct3.calcIrms(no_of_samples);
if (CT4) for (int j=0; j<5; j++) ct4.calcIrms(no_of_samples);
}

See the 'sticky' post at the top of this forum. There's a new emonLib available for testing, which I think fixes the problem that Jack Kelly's change attempted to solve but which ended up giving you totally wrong values.

Robert: I just tested the dev version and the problem is indeed solved. Thanks!

Just tested myself and it works great. I've merged the 'Dev' branch with the changed into 'master' emonLib and removed the Dev branch. 

Thanks guys!